FredChap's blog

We Are Doing Daily Standups, So We Are Agile

Frederick Chapleau [MSFT] — Sun, 28 Apr 2013 23:29:00 GMT

Daily standups are a really good practice, even if a team is not using an agile methodology. But let’s try to clarify things, because the statement “We are doing daily standups, so we are Agile” is a little confusing.

What is a Daily Standup?

A daily scrum is one of the most hands-on activities of the Scrum framework. There are rules a team should follow when standing up, like being prepared, on time and time-boxed. The main goal is to address what was done yesterday, what you are going to do today, and what are the road blocks.

As you can see, a daily standup is not strictly related to Scrum or Agile. I often found that daily standups are part of a routine even if Scrum is not used, and I also found teams that were doing daily standups while using a waterfall methodology (!).

So, what’s the relationship between daily standup and agile methodologies?

The Daily Portion of the Methodology

Daily standup addresses the daily portion of the methodology, so it’s a part of an agile methodology. By doing a standup, a team is able to react quickly to changes, quickly address roadblocks and enable better communication between the team members. But there is more. Obviously, the daily portion does not address short and medium-term planning, called iterations or sprints in Scrum. Iterations are:

Short time frames that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. (ref)

Each iteration is part of a release, which is part of the overall agile vision. Without going into the details or trying to summarize the whole methodology in a couple of paragraphs, I will try to list a couple of things that can get your team nearer to being Agile.

Some Activities, Milestones and Artifacts

Daily Standup

If nothing else, don’t neglect this daily habit. In my experience, it’s the core of the methodology because it enables communication within the team in such a way that everybody focuses on the real, tangible goals without getting bogged down by details.

Iteration or Sprint

Doing iterations is a must, but it’s the hardest thing to achieve. In traditional waterfall models, the developers were working on strict requirements that were defined and approved by the stakeholders prior to beginning the development. The agile methodology allows the customer to change their mind, therefore the development effort and specifications cannot be determined upfront. This is one of the most challenging aspects of agile to implement when a team is used to development in a fixed-requirements context.

Product Backlog

Establishing a product backup will clarify the real orientation of the software and provide transparency to the stakeholder(s). This backlog is also a great tool for prioritizing the features and focusing on the real value.

Sprint Backlog

The sprint backlog is the list of requirements the development team should address in the current sprint. Each item has a related, quantifiable effort, and the total effort for all the work should fit in the current iteration. Understanding that will help focus the development team on the specific requirements, instead of going in every direction trying to develop the whole software in the first month.

Burn Down

Visibility, visibility and visibility. One of main arguments for using an agile methodology is to have visibility for the stakeholder(s) throughout the development. A burn down chart graphically compares the projected burn rate with the current burn rate.

Only the Beginning

Again, I am not trying to summarize or to describe the whole methodology in this article. These activities, milestones or artifacts are only some that I have found to be important in making a team be more agile and adaptable.

Afterwards, there are some other activities that could be employed, such as using stories to describe the requirements, estimating story points to evaluate the efforts, or even using planning poker as a way of giving points to a story.

There are also many tools that can be used for reporting and to track work item efficiency (Yes, I am talking about those things you saw in Visual Studio). I will discuss those tools in more depth in the following posts, because those tools are really useful when it’s time to be more productive in our management of agile projects.

Why being SMART?

Frederick Chapleau [MSFT] — Sat, 30 Mar 2013 12:42:00 GMT

The Importance of Being S.M.A.R.T.

Many methodologies are trying to align technology related-activities to the purely business activities. With Premier (forgive my non-subtle link to the Microsoft Premier Services), we are using PSDM (Premier Service Delivery Methodology), which is essentially anchoring activities with the real value provided to the business. With PSDM, we are defining Goals and Value in such a way to reveal if related activities are providing value to the business.

Setting objectives can be a hard task, simply because they are not activities or tangible deliverables that can be executed directly. Objectives are big-picture orientations toward business goals, enabled by purposeful activities. Because of their nature, it may be gauge the quality of an objective, at least in the early stages.

Using SMART characteristics are a way of validating objectives by gauging if they are meeting selected criteria. Let's discuss each of them and illustrate them with real life examples.

Specific

Being specific can be difficult. If an objective is too specific, it can be hard to achieve; if it is not specific enough, it can be hard to measure. So the rule of thumb is to be specific enough within the context of the objective. If the objective can be removed from the context, it’s because it is not specific enough. On the other hand, if the objective is too specific, generally you will be able to merge it with another one. Here are some objectives that are either too specific or not specific enough.

Too Specific

The IT Department should be able to attain 82% resolved Exchange Incident related to uptime of the T1 link on the east coast, when the west coast link is used at more than 80%.

Obviously here the circumstances are too specific to be able to measure without deploying some really deeply integrated reporting tools.

Not Specific Enough

The IT Department should be able to attain 82% resolved cases.

Where are the cases? All type of cases? Only for customer requests? If a client is calling because his Xbox is not working, is it impacting this number?

Measurable

Being measurable is one of the most important characteristics. It is the key characteristic that will provide empirical evidence as to whether an objective has been met or not. An objective is measurable if its accomplishment and success can be described with a simple “Yes” or “No.” It is the difference between qualitative and quantitative.

Not Measurable

The code should be well documented, so that any consultant could easily jump into the project.

How can the code be well documented? If a line of comment is added to each code file, is it enough?

Measurable

Every Class file and Method should be documented using the standard XML comment format and method; more than 50 lines of code should contain Region and describe what is in the scope.

This very specific objective could be automated using check-in policy in Team Foundation Server, and the measure can be reported with the TFS report engine.

Attainable

This characteristic is also known as achievable. From the outset, there should be at least one way of achieving the objective. Even if it’s difficult or if it requires many resources, it should be achievable.

Achievable

Reduce help desk calls related to the ERP system by 30% within 12 months.

30% can be enough for the majority of IT departments, and having a reasonable timeframe allows for the objective to be well understood and then achieved.

Not Attainable

The ERP Project should be realized by the end of the fiscal year.

It’s not an error, because the context could change. If in this context the ERP must be implemented in all departments of a 5000-employee company, even if all available resources are dedicated to the task, it is not realistic that this could be achieved.

Relevant

Objectives should be linked to the business. Even if an objective meets all criteria, it’s not relevant if it does not provide value.

Realistic

The automated unit tests should cover at least 80% of the software code.

This could be related to an R&D department and it is adding value to the business.

Irrelevant

Improve the backup strategy, so that a backup is done at least once a day.

This could be relevant, but it’s completely irrelevant for an R&D department not responsible for the backup strategy.

Timely

If an objective cannot be achieved in a specific amount of time, it’s not achievable at all.

Timely

No bugs should be discovered by at least three consecutive passes of unit testing each day for a period of 3 months.

The period part of the objective pertains to the Timely characteristic. Without this part, there is no single point in time where the objective could be met.

Infinite

The software code should not contain bugs.

This objective cannot be validated until all licenses of the software are not used anymore.

Conclusion

Being SMART is one of the most efficient ways of setting clear objectives. SMART objectives can define a solid base of discussions and can be easily aligned with a mission that should provide value to the business.

After defining them, everything related to them makes more sense. Those objectives are often defined as Key Performance Indicators (KPI) in the modern business world, with specific examples that include Business Intelligence, Balanced Scorecards and Global Performance Initiatives.

-f.

The Evolution of Authentication

Frederick Chapleau [MSFT] — Sun, 24 Feb 2013 22:27:00 GMT

Authentication versus Authorization

Authentication is often confused with authorization. I’ve even heard of an eCommerce course wherein the teacher was using both terms as if they were interchangeable. In fact, there is a huge difference between them. Authentication is used to authenticate a user with confidential information known only by the user. After the user is authenticated, the only assurance we have is that the user is the one who created the account and provided the confidential information. This information does not include enough detail to know if the user has access to a system-specific function (at least it shouldn’t).

On the other hand, authorization is used to provide information about system-specific functions. Authorization is often used at the application level, after authentication is complete. Once the user is authenticated, the account is authorized to use some functionality in a system by the authorization provider.

When considering authorization, AzMan is usually the component of choice. Many other products are using their own authorization mechanism; SharePoint and Dynamics CRM are a couple of examples.

Now let’s discuss authentication. Before looking toward future trends, it’s necessary to explore some history. We will review why LANMAN is bad, Kerberos is complex but at least can use delegation, and Federated Authentication is the ideal choice.

A bit of history

Once upon a time, there was a need to authenticate users when computer began to talk to each other. Obviously, users wanted to keep a minimum of confidentiality, and administrators needed the ability to restrict access to specific resources.

LANMAN

One of the first implementations of an authentication mechanism was the LAN Manager or LANMAN. This technology was based on OS2 and was co-developed by IBM and Microsoft.

The concept was simple. An LM Hash was made of two parts, containing 7 characters and encrypted with a static key (without a salt). This method of encrypting passwords had many drawbacks. For one thing, because it was divided into two parts, all passwords with less than 7 characters had a static second part, which makes a password really easy to guess.

Also, passwords were not case sensitive!

To address these security issues, a new version of LANMAN was created especially for the Windows NT platform. It was called NTLM or NT LAN Manager.

NTLM & NTLMv2

Source: http://msdn.microsoft.com/en-us/library/ff647076.aspx

NTLM is a more complex authentication protocol. It uses three messages to establish the identity of the client. Without going too deep into the details, the underlying cryptography algorithm is mainly MD4 and DES.

A second generation of the protocol was released to make it more secure. NTLMv2 employs the HMAC-MD5 algorithm instead of MD4.

Both of these protocols are secure enough, but once the user is authenticated, he or she is authenticated against a single server in a specific context. If the authenticated service requires access to another resource on behalf of the user, it cannot use those credentials to access the other service. One of the solutions is to use a service account and rely on the system to give the user appropriate permissions.

To mitigate this problem (even if it's more a new need than a problem), a token-based authentication mechanism was created – Kerberos.

Kerberos

Source: http://msdn.microsoft.com/en-us/library/ff647076.aspx

Kerberos is a ticket-based system that can authenticate a user and delegate the authentication ticket to another service. By doing that, the user is always authenticated for all the hops in the architecture.

In order to issue a ticket for a specific service, the service itself must be registered in Active Directory. A Service Principal Name is registered for each service/address/port combination and associated to a specific machine.

Kerberos relies heavily on infrastructure components. The first is the KDC dedicated to Kerberos, and the second is Active Directory, which is the authentication source.

Authentication, as of Today

Both NTLM and Kerberos are widely used in the corporate world, where all the services are consumed in the local (or wider) network. With the advent of the cloud and other Software as a Service (SaaS), many resources are located outside the organization. Kerberos, which depends upon corporate components, cannot be used outside the organization, except if system administrators wants to open what is usually known as a security breaches.

As always, security is a challenge. The challenge is even greater when there is a mix of on-premise and online services. To address that, a new way of authentication called Federated Identity is now widely used. Office 365 can use Federated Identity, as an example.

Federated Identity Basics

Federated authentication is a superset of the well-known SSO (Single Sign On). It’s a superset because it is not only limited to authentication, but also includes additional information. The authentication part is usually known as Federated Authentication.

Standards

Many standards can enable Federated Identity as of now, such as OpenID and OAuth. The main difference between these two cases is that the first is for Authentication, and the later is for Authorization.

As an example, if a user wants to access a website, OpenID is the standard that will enable the user to validate that his or her identity. If, on the other hand, the user wants to upload photos to a website, OAuth will be the standard that authorizes the user to access this specific functionality.

The Microsoft Take on Federated Identity

To enable those standards, there is a complete set of components under Identity Management. The most common ones are ADFS, along with the not-so-new foundation available that is addressing Identity in general, called Windows Identity Foundation (WIF).

Active Directory Federation Services (ADFS)

Source: The .NET Developer's Guide to Identity

ADFS is based on the WS-* specifications, which are industry standards for security from the W3C. Those standards include WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security and WS-Trust.

ADFS use a claim-based approach. The simplest way of explaining that is: you trust the claim received if you already trust the issuer. There are some excellent whitepapers on the subject.

Access Control Service

On the other hand, you might want to use external services to authenticate your user. Windows Account (Live Id), Facebook and Google can be used as Token Issuers for a claim-based system. To leverage all those Token Services without modifying applications, the Access Control Service (ACS) can be used as a token provider. Afterward, ACS can be configured to accept Tokens from many providers and can perform translation and transformation of tokens so that applications can expect the same format. Obviously, Microsoft offer a great ACS in the cloud called Windows Azure Active Directory Access Control. It can be used by any application, and can authenticate users from identity providers like Windows Live Id, Google, Yahoo, Facebook and any ADFS 2.0 servers.

A great (and free) book is available online concerning MSDN: Federated Identity with Multiple Partners and Windows Azure Access Control Service.

Conclusion

From the unsecured LANMAN to the federation-enabled Azure ACS, the objective remains to give the appropriate rights to the appropriate persons. We began by trusting the users with LANMAN/NTLM; afterwards, we trusted servers using delegation in Kerberos; now, we are trusting “trusters” with Federated Authentication.

Even though many of those security mechanisms are secure enough, users are still authenticating with passwords. What will be the next step? Some are saying that two-factor authentication will be a solution. Some are already trying hardware based authentication mechanisms, and there are already some alternative passwords, such as gesture on the Surface. With the arrival of the augmented reality trend, and the future vision from Microsoft, no one can tell what will happen next.

-f.

The Value Style

Frederick Chapleau [MSFT] — Sun, 13 Jan 2013 17:40:23 GMT

Today, software developers have a slew of alternatives. Many technologies are available, and making the right choice is always a challenge. Azure? WCF/.NET? Web 2.0? … Access? Why choose one architecture rather than another? All too often, I find people wielding the "Golden Hammer" – the tool of greatest familiarity. When you really understand a technology, you can always find an argument to use it. Ultimately, the chances are high that the familiar tool will be the tool of choice.

A simple scenario

In this article, I will describe different styles in a scenario where a user is attempting to generate a report based on two pieces of information, Persons and Matches. The user consults an Excel Spreadsheet that contains values for each Person and for each Match like this:

	Match 1	Match 2	Match 3	Match 4
Person 1	4	3	8	5
Person 2	1	7	4	2
Person 3	9	10	5	8
Person 4	6	8	10	7

A report for each Person with the Matches and the associated scores would look like this:

Person 1
Match 1	4
Match 2	3
Match 3	8
Match 4	5

This report would be customized to insert images, add colors, etc. In addition, this report should be in PDF format.

Styles

Let’s now consider different style approaches to the above scenario.

Geek Style

The geek style will most likely entail an Azure, MVC, JSON-enabled application. The developer’s biases will revolve around new technologies and the low cost of deploying this kind of software in the cloud to avoid maintaining infrastructure.

In the end, this is a good choice, and the client will not have to refactor the application for a couple of years. However, not all clients are technology savvy, and they may not want to rely on technologies that require a Geek approach to implement any changes. For a simple application, after all, this may be a little excessive. I call that Programmer’s Golden Plating.

Web 2.0 Style

The Web 2.0 style developer will also propose a recent approach without going too far or deeply into the most recent technologies – maybe just a website using ASP.Net with some Ajax callbacks to make it more responsive, along with some third-party controls to avoid re-inventing the wheel.

There is no problem with this approach (like the last one), except that the client must buy hosting for the ASP.Net website, and must rely on a developer to make changes. Is that really required for the scope of this application? Surely not.

OLE Style

The OLE style is ruled by the "it’s always worked this way" mode of thinking. The developer will propose a client-server application, possibly based on recent technologies such as SQL Server Express and a fat client in .NET. This architecture is simple and straightforward, with almost no infrastructure component.

The OLE approach could work, and the probability of finding resources to maintain those technologies is quite high. However, the client’s actual needs may only include the ability to modify a report or modify some screens. Is a full-fledged application really required for a three tables application?

MOS Style

The MOS style developer (where MOS stand for Microsoft Office Specialist) is an Office power user who knows the ins and outs of development using Office products. This variety of developer may suggest an Access Database, with a form for data entry and a reporting functionality.

In this case, there are no infrastructure components, and the user can modify every bit of information in the database. The user can even go as far as modifying the report or adding a new one. While it’s not comparable to the aforementioned styles, it is a hybrid between the current implementation and the development of a compiled application.

Maybe that is the satisfactory solution to the need expressed by the client.

Value Style

The value style is an entirely different approach to the problem. It is exactly what it sounds like – a focus on the real value of the application. Sorry people, the software is not the real value here. The value is always what the user can achieve using that software.

So what is the real value in this scenario? It’s to create a printable format of transposed information automatically. All the other styles can achieve that, but value style makes no mention of stability, performance, centralization or technology. So, what is the more straightforward way of delivering the value in this case?

Right now, it’s an excel sheet. We can print Excel sheets. We can transpose information (the paste options are pretty extensive). And we can automate things using macros.

One hour later and the solution is delivered – an Excel workbook with a macro that generates sheets based on a template sheet using the transpose paste option of Excel. After executing the macro, the client only has to use the standard save options of Excel 2013 to save it in PDF format.

Final Note

Certainly, this is a scenario with an obvious implementation that could be discovered in less than 15 min. I am not saying that any of these technologies are better than the other, and I am definitely not saying that Excel is the solution for everything. The point here is to focus more on the value and less on the implementation. We should always deliver quality software. We should always think about all "-ty". However, we should also think about the real value in what we do.

A simple way of finding value begins with asking a simple question:

"What is the benefit of using software instead of using pen and paper?"

-f.