How Agile are you?

Does it really matter if your Agile implementation is not ideal or complete? It does. However, it is more about the journey than the destination! Knowing your limitations and weaknesses will help you improve towards the goal of being more agile. In other words, it is important that you continue to inspect and adapt.

There are multiple tools to help you evaluate the current state of your Agile process [1,2]. The one I have used is the Nokia test [1]. It is not a perfect measure of where you are, and the scores can be debated. Agile processes are too complex and subjective to summarize to a single number or score. So focus on big areas and not on specific scores.

A good analogy is If you were trying to measure someone’s body temperature. The Nokia test would be closer to putting your hand on someone’s forehead than to using a thermometer. It will give you a sense of how above normal the body temperature is, but it won't tell you if it is 103F or 104F.

In 5 years using Scrum, our team has gone through multiple adjustments. Sometimes these adjustments were necessary because of internal factors, but most of them came from external ones (Reorganization, skills available, etc.).

It’s sad to say, but there were phases of our team where our Scrum implementation was almost perfect, but right now it is what Sutherland would call "Scrum Butt".

The Nokia test allowed me to perform a sort of Strengths, Weaknesses, Opportunities and Threats analysis [3] (SWOT). It showed me where our process is strong and needs to be nurtured, but also where we are weak and need to shore up support.

Not surprisingly, our weaknesses are on areas we thought we shouldn’t play a role. For example, we have a QA department that doesn’t report to the team, so QA practices are not considered seriously and left to that department to manage. We are working with the QA team on improving our common work practices.

Another area where we were weak was Agile Specifications. We don’t necessarily have Business Analysts on staff, so we are now using developers on creating these. Remember, Agile promotes specializing generalists.

As it is the case with iteration retrospective, perhaps we should invest on doing process retrospectives. It should not be as often as the iterations, but often enough to have an impact on the project.

A source that was very helpful as I created these action plans was John Little’s blog series on the Nokia test [4]. It helped me create persuasive arguments to present to the other teams involved and upper management.

Using an external tool helped me take a step back and assess where our team is in our journey to being agile. It was a great experience that I intend to repeat more often.

References:

[1] Online Nokia Test

[2] Comparative Agility

[3] SWOT link

[4] John Little’s blog series about the Nokia Test

Do Matrix Organization Foster Bad Behaviors?

Matrix organizations deliberately creates a power struggle between project managers (PM) and resource managers (RM) causing the whole system to be dynamically unstable. In other words, energy in the form of conflict resolution must be spent to keep the organization stable and working efficiently towards business goals.

There are three major types of matrix organizations: balanced, weak and strong, which are defined by the PM role in projects.

In a weak matrix, the PM is responsible for coordinating the tasks, not for actually delivering them. Their role is to be the liaison between multiple RMs delivering work.

As a result of the RMs managing all the work, PMs have less control over the project and work unrelated to the project might get done without business approval.

In a strong matrix the PM and the resources assigned to the project work closer together, and the PM is accountable for the delivery of the project. The RMs are responsible for human resource tasks like hiring, training, and so on.

This organizational type promotes a healthier alignment of resources to business goals to the detriment of technical tasks that might not have clear upfront business value defined (healthy refactoring for example). The team is concerned with the success of the project and not the long term health of the system/product.

To address this issue, sometimes purely technical structures are created. Architecture Review Boards get formed to make sure that systems are being designed properly for example.

Balanced matrixes are the ideal where the power is perfectly shared between PMs and RMs, little direction is provided though on how to achieve it. It seems to rely on interpersonal skills of RMs and PMs.

The saying “absolute power results in absolute corruption” does not apply when the interests and the power are perfectly aligned. In other words, when the person responsible for the business success of ventures has absolute power to make decisions on its behalf the corruption is good for that venture.

In matrix organizations, the power struggle is often between well intended technical individuals (PMs and RMs) trying to best serve the business. When there’s a clear business owner that yields strong power, conflicts are cleared and addressed quickly in a way that best benefit the overall venture.

I should be clear though that conflicts and struggles might not happen only between PM and RMs, but amongst the multiple RMs as well and that this is not the norm necessarily.

Concluding, a matrix organization requires energy to resolve conflicts, without a clear mechanism to resolve them, the organization might regress into outright bickering.

Team Preservation vs. Prioritization

Keeping a team together is important, but not to the point where prioritization is hard.

Shared services teams are a necessity and they won't go away. The problem with them is that backlog prioritization is hard. You need to identify a product owner that is effectively a proxy to all the other users. This proxy's job is thankless; he or she has to make multiple competing stakeholders agree on priorities without an incentive to collaborate.

One way of solving this issue would be to group and disband teams as projects come and go. The Storm, Norm and Perform [1] theory for teams suggests that we keep teams together as long as possible and this approach would go against it.

So how would I solve this difficult problem?

I thought about:

1. Have a proxy for clients responsible for accommodating and negotiating priorities across stakeholders.
2. Dedicate resources or hours to specific stakeholders.


3. Form/Disband teams as projects come and go.
4. Create a cap and trade system similar to the one described on [2].

Lately, I have been leaning towards option 4 a lot. In short, every stakeholder is given a number of hours, or percentage of the team's time; a cap. They are allowed to negotiate their hours (or points) with the other stakeholders, but once the iteration, or some other time period starts, any points/hours that were not used would be forfeited in a use it or lose it fashion (I still have to think this one through).

This approach is not infallible. It can lead to context switching if all stakeholders decide to exercise their options in a specific, or worse, all iterations.

On the other hand, this could lead to some interesting behaviors, where certain stakeholders with medium priority projects could negotiate their caps at a premium with stakeholders that are "desperate" for completing projects. In other words, it rewards collaboration. It also allows the shared services team to measure how much a stakeholder "conceded" or not, eliminating the squeaky wheel effect [3].

Another interesting consequence is that it would encourage better portfolio management on the stakeholders’ part. I don't mean to reduce acceptance to change, but committing the team to a task/story that has low return value, would equate to throwing away money.

The cap and trade system seeks to reduce conflict resolution for all involved and give an incentive to negotiation and collaboration among stakeholders. I have not implemented such a system and have not completely thought it through, but it seems promising.

Besides all of that, it could lead to an interesting game.

What problems do you think I'm going to encounter? How did you solve this problem before? What were your good/bad experiences?

Please leave a comment below :)

[1] http://changingminds.org/explanations/groups/form_storm_norm_perform.htm
[2] http://www.americanprogress.org/issues/2008/01/capandtrade101.html
[3] http://en.wikipedia.org/wiki/Squeaky_wheel

How stable should velocity be?

If you are estimating story size instead of duration, velocity is what will allow you to determine project duration and thus cost. In such an environment, velocity is an important metric and needs to be monitored accordingly.
As I wrote back in April, we have been collecting data to see if we were improving or not our velocity. My original intent was to find what influenced velocity however, that goal became making sure that velocity is somewhat stable.
As we started to collect metrics (Total # of team hours available, # of points with clear definition of done, # of distractions and # of blocks) we started to pay more attention to velocity. It was interesting to see that velocity was varying beyond what we expected. We could always explain why velocity went up or down, but it was varying regardless. One of the issues we found was that story estimates were wrong. The team inadvertently started using a different scale that turned out to be too small. In other words, a story that used to be a 5 became a 1, so the stories that were a 1 had nowhere to go.
If you are using story points, you need to make an effort to make sure that the relative sizes of stories are valid. As you work through your stories you look for stories with disproportional sizes. A story of size 5 must be a little bigger than twice a 2.
I regularly use a room painting problem to explain story points. It works well because people will tend to estimate the time it will take to paint a room by the number of walls and their sizes, but the number of cuts (windows, doors, etc.) is what really determines how long it will take. So once we go through the exercise of estimating painting multiple rooms based on sizes, I introduce the cutting variable and thus have the team re-estimate the "project". In other words, when the team learns something new about a set of stories, they should go back to the backlog and re-evaluate their estimates.
During this effort of collecting metrics, I did create control charts for velocity, but these weren't as useful as I expected. If you just observe velocity you can already tell when there's a problem, you won't need control limits for that. Pay attention to what is contributing for your velocity to vary. If it is distractions, make sure they go away!
The participation of the team is important. They have to share your ideal that this is intended to help them achieve their full potential and that cheating the system will not help anybody.
Velocity shouldn’t swing much in a single iteration. It should be stable and somewhat predictable. If it does you have a problem and need to address it.

Rewriting Systems and Waterfall: A Common Theme?

If batch size is the number of lines of code being delivered to production, completely rewriting systems and waterfall have one thing in common: Big Batch Sizes.

There are good reasons to rewrite your software. Like it being dependent on technology that is no longer supported [1]. The belief that the code is a mess in not a good one [2].

When you make the decision to rewrite a system, your customer will not get any benefits until your brand new system catches up to the features already available in the old one. In other words, the batch size is as large as the current system. Perhaps a little bit smaller, but not much. Similarly, in a pure waterfall project, your customers will not get the benefits until you finish it.

To reduce the batch size you could slowly rewrite small parts of the code until it gets to the desired state (Refactoring), or migrate the code feature by feature (Vertical Slice Migration). Let's call these approaches Small Releases.

Vertical Slice Migration and Refactoring aren't always attainable. Vertical Slice Migration might not be possible if the system you are replacing is tightly integrated or doesn't have an easy way to make an external call for example. You shouldn't use Refactoring if the desired state is not a natural progression from the current one. That's normally the case when you are moving platforms or languages (i.e. COBOL to Java).

Reducing the batch size doesn't reduce cost, it allows your customers to give you feedback and realize the benefits of your efforts early. Each release you make to production has test, migration and deployment costs. Likewise, the waterfall method can also be cheaper than agile if you can fix requirements upfront (From my experience this is unrealistic in most cases). If there's no need for early feedback, doing multiple releases only makes the project more expensive.

As for the risk of the change, you could argue that Small Releases incur greater risk. After all, you are making multiple changes and that increases your probability of error. I think the opposite is true. By making small changes you are in better position to evaluate the risks and take the right approaches to mitigate them. It is easier to manage an incremental upgrade than
it is a full system deployment. This is also the case in a waterfall project where by doing a big bang release, the risk is concentrated in one single event: The Release.

In summary, a big batch is cheap to produce, but the consequences if it is bad can be severe.

[1] http://www.nytimes.com/2002/05/12/us/for-parts-nasa-boldly-goes-on-ebay.html
[2] http://www.joelonsoftware.com/articles/fog0000000069.html

Deploy Every Iteration?

How would you change your software development process if you had to deploy to production at the end of every iteration? Do you see yourself requiring "hardening iterations"?

Deploying every iteration is not for the faint of heart. You need to ensure that the software you are releasing is solid and integrates well with the other pieces. It requires you to have your engineering practices really down, reducing the time you spend in doing the release (a.k.a. hardening iterations) as much as possible.

If you look at the activities that happen in a hardening iteration to enable a release, you generally have building the software, reviewing code, regression plus load testing and at last deploying it. This set of activities will probably grow or shrink depending on the regulatory environment you are in.

To reduce the time you spend building the software you need to automate your build process as much as you can. In the Java space you can use tools like Ant and Maven, for .Net Nant is an alternative. Maven is useful because besides just automating the build it generates a nice web site with reports about the software you're building.

Once you have a good build, i.e. no compilation issues, you need to check it to make sure it has no regressions or bugs. This is probably where automation will give you the most benefits. The shorter you can get your regression tests to take, the more time you will have to actually write code. There are plenty of tools out there that will let you automate your tests. If you are writing web applications you might want to look at Selenium. Regression tests are not the only requisite to deployment in some shops, you might also need to load test your software to make sure you still satisfy your performance service level agreements.

Finally you need a fast and easy way of deploying your application. Here I have no tool advice for you. On the bright side, if you are releasing every iteration you won't have a lot to deploy and thus it should be quick and easy. The longer you code, the more complex your deployment might be.

As you add the three automation pieces above, consider implementing a continuous integration process. It would allow you to eventually have code travel from the software developer mind to production in no time! A few free tools in this space are Hudson, CruiseControl, Continuum, etc.

In an Utopian world, every time a software developer commit a change to your Source Code Management system (you have one of those, right?), you would repeat the whole process automatically and send the software to production. I do not recommend you to do this, except the simplest of the cases!

As you can see, if you inspect your deployment process constantly, you will be able to eventually spend little to no time on "hardening" your software for deployment. Repetitive tasks should be left to a computer, not to a highly paid professional ;)

People Over Process and Tools

People and Interactions Over Processes and Tools. In other words: Brain over Fingers.

If Agile values people over processes and tools, why does it require so much automation? Reality is that people is good at creative tasks, so in order to really use their potential we need to free people from tedious and sequential tasks. People: We need your brains not your fingers!

Perhaps my biggest challenge implementing Agile so far has been convincing people to let go of their repetitive tasks and automate their processes. This is not always the case with software development professionals, but in general it is the case with the other "delivery functions" (QA, Operations, Project Management).

I'm not sure if it is related to people's background, but I find that QA analysts and System Engineers that were once developers are more receptive to automation and have greater success with it.

It is not hard to convince a developer to automate his build process for example. In fact, I haven't seen a manual build in a long time now. That's definitely not the case with QA Analysts and automated test cases or System Engineers and their deployment or monitoring processes.

The way I normally approach this issue is by selling the benefits to the professional in question. I show engineers and analysts how much easier and pleasurable their lives would be if they didn't have to do the same repetitive task over and over again. For example, I tell QA analysts how much more challenging their job would be if instead of executing their tests if they spent most of their time coming up with new test cases. In this case, we need QA analysts to use their brain to come up with test cases and not fingers to type or click the mouse.

By shifting the work of the QA analyst to test case development and automation we are now using their brains and not only their fingers. 

It is true that automating test cases might require as much software development skill as coding the system being tested. In cases like this, I'd have the QA analyst define the test cases and have developers automate them. I found that QA analysts are sometimes comfortable reading the test code and are willing to "audit" the automated tests to make sure they are indeed covering their intended cases.

Deployments is another area of the software development process that is ripe for automation. How much better life would be if instead of spending a few hours deploying an application in the middle of the night, System Engineers spent those hours coming up with scripts that would deploy the application in minutes? What if they spent time figuring out how to break the deployment apart enough to be able to have all of the components in production inactive ahead of the deployment? These are tasks that require brains and not fingers.

Once again, we need your brains and not your fingers!