Hello World, Hello Quickest end to end Implementation

What is the fastest your Agile team can bring something to market? If you don't know, it's time to find out. You might be surprised at the answer. When working with clients who struggle to understand potentially shippable, I found that talking about releasing a Hello World story is a good way to learn how well their development, technology, and QA processes work.

Recently, I worked with a ScrumMaster who said his team would need more than 1 day but less than 2 to build, test, package, deploy, and then system test the installation. This was much better than his first answer: we don't test the package during each sprint, we don't do a Sprint Deno because we can't. Talking about adding a Hello World story is a good way to structure people's thinking about an easy to visualize goal. Then it's easier to talk about what impedes realizing the goal.

It's also a good way for the team to learn how to do all the engineering practices for from one end to the other: acceptance test, tdd, pair, ... And measure the overhead (what impedes them).

Agile Resource Management and the "Perfect Method"

Managers whose companies are in the agile transition period often have questions about resource management. With Agile, it's quiet different than what they are used to. If we understand why "traditional methods" exist how they are, we'll better understand what activities are no longer relevant for an Agile project.  Here's a look at Agile's Planning Game versus traditional project management and resource allocation.

The Planning Game
The goal of planning is to get the most value for the business/customer for the amount of time spent on the project. To achieve this, we need to get development and business working well together. If the relationship is poor or if there are many layers of middlemen (management, analysts) separating the layers, then the planning outcome will suffer, even the project is considered an Agile project. This is why XP and Scrum both want the customer (or the Product Owner--one person who can make decisions as if she were the costumer) at the planning meetings and interacting with the team as often as possible. Agile methodologies also ask that the team work differently together: cross-functional, small releases, pair programming, production quality code released at the end of each iteration, etc. (See the following for more: http://www.extremeprogramming.org/rules.html)

Traditional Project Management in the Enterprise
Traditional project management evolved into having layers of people between those who can make decisions about requirements and those who are building the software. Among other reasons, this was done as a way to scale work out to hundreds or thousands of people. A number of middleman roles were created and these middlemen worked more or less as a negotiating layer between the business and the development, maintaining records of decisions. This slowed down decision making due to the team or business working through layers analysts/management to communicate with each other, and often using media (documentation, email) that was inferior to face to face communication.
The outcome of having a slow decision and communication process was that people on both ends found other things to do while waiting: business people started another project and generate business specifications; and the development team became managed by a resource manager who found another project to work on. These other projects executed using the same traditional planning style. Because making decisions was slow in this process, following THE PLAN became very important because changing the plan meant more meetings, more decisions, and more waiting. Team members could be on three or four slow moving projects. Resource managers were busy in making sure people's time was as fully allocated. To make their management easy, each project needed to add to THE PLAN how they were keeping each person busy. If a project's PLAN changed, this created change in personal (adding or removing). If estimates were found to be poor, people would do their best to come as close as possible so that THE PLAN wouldn't change, and sometimes a schedule slip was disguised for months. If the business wanted something different done, this would create a change in THE PLAN that everyone wanted to avoid. THE PLAN evolved to measure effort in Perfect Engineering Days (the "Perfect Method"). If a task takes 11 Engineering days, and you have 5 Engineers, then it will finished in about 2.5 days multiplied by some overhead constant to represent meetings, email, and communication. So those 11 days are "perfect engineering days."

Agile and the Planning Game in the EnterpriseThe biggest reason to move to Agile methodologies is that they make business sense. Time to market is an important measure of a company's ability to bring new products to market. If your product is up for sale before anyone else has a similar product, you have a huge advantage in being the only choice. If your 2nd generation product is out for sale while the competitors only have their first generation, you have a captive marketplace that can only buy from you. Some members of the market will wait for their favorite vendor, but they won't wait forever.

An Agile team team is set of people who work on one project because for a long time, we knew that multi-tasking over multiple projects created "wait states." Wait states occur within the project and wait states across all other projects that the engineer worked on at the same time. For example, engineer A on project Z waited for something from engineer B, but B worked on his other project V because his manager wants to see more progress because V is becoming the "long line" in a multi-project release. After engineer A spent time discovering the wait state, she found something else to do: re-remembering what her other project, Q, was doing, setting up a build environment, and paying other Costs of Task Switching. Everyone knows that multi-tasking adds to overhead, it's only a matter of debate about how much overhead, and finding an alternative. The trouble is that multi-tasking breeds more multi-tasking, as you saw with engineer A.

The Agile Alternative
Part of Agile's better execution speed is realized by breaking away from making plans that fixed business requirements, features, and individual resources together. Everyone on the team is full time on one project until it releases, and let the team manage balancing the work load. Agile's productivity measure, Velocity, is a team wide metric. Velocity measures team productivity and is updated each iteration. Perfect Planning method only estimates cost of effort of an individual to do the work during a perfect day. Velocity will show the impact of process changes. Perfect planning will not as it's only measuring the cost which will need to be updated if the team discovers they need to "double their estimates." Velocity measures results of execution. Perfect Planning measures time for a work item.

Each iteration we have a Planning Meeting where we play the Planning Game
[source: http://www.c2.com/cgi/wiki?PlanningGame] where the team's latest Velocity and their estimates of the backlog of stories/requirements are used to give the business the most up-to-date data on what stories can/cannot be done. Re-planning happens each iteration based on this information (stories are adjusted, people may be added/removed from the team). We expect to re-plan each iteration, where Traditional project management expects THE PLAN to never change (which is a false assumption since it always changes). The team, uses Velocity to guide how much work to pull into the forthcoming iteration. Perfect Engineering Days aren't used because it brings along with it a stipulation that only one person is working on each task (and over simplified the ability to divide and conquer). The team members may use the practice of Pair Programming in order to have fully reviewed code, better designed, and a fully cross functional team where everyone understands what the software is doing. (Note: You could choose to use Perfect Paired Engineering Days http://xprogramming.com/Practices/PracIterations.html. But there are better systems out there which are a better fit for how human brains work: http://www.renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf ) [*]

What's a manager in a transitional organization to do?
If people demand that you express your team's allocation by engineering days so they can add it into a planning tool, then find a way to make them happy without having "resource allocation reporting" affecting your team's agile process (Pair Programming, using Planning Poker with a numbering system rather than "Perfect Method", cross functional team members, ...). For example, if you have six people on your team, and based on the team's most recent Velocity, they are going to finish the most up-to-date version of the backlog in two months, then you have twelve engineering months. Find a way to fill out the report to make the organization happy. Eventually, and by educating your organization, you'll be able to drop this "Perfect Method" Wrapper.

"Perfect Method" Wrapper Patterns
Since many companies are in similar straits when transitioning from a traditional organization to an Agile organization, many project managers turned ScrumMasters or XP Coaches are faced with this problem over and over. Wouldn't it be nice to have a list of solutions that people have done to solve this impediment? That's where you, dear reader, come in. If you're in a transitioning organization or have just finished doing a transformation, use the comments section (moderation is turned off, so go for it) beneath this blog to describe what you did or going to try to keep your team agile when your department wants you to report on your use of human resources via perfect engineering days.


[*] I'm more proscriptive than James Grenning in that I ask teams to resist adding more numbers into their numbering system. If you're using the Fibonacci system (1 2 3 5 8 13...), stick to it! Otherwise the team'll waste time deciding between 5 and 6 rather than quickly finishing planning by deciding between 5 or 8. I'm even more extreme in that I recommend a geometric series instead (1 2 4 8 16 32) which has even bigger gaps. Having gaps are important because humans are better at making quick decisions over these gaps between numbers rather than a long debate with a liner system where there isn't much difference.