3months Agile Consulting Blog

Funny - I was so sure I won’t prepare a presentation for the agile barcamp tomorrow but instead just talk straight from the heart. Yet here I am writing down my thoughts of how to best communicate the benefits of both an agile approach to software development but also to project management. So without further ado and in reminiscence of the 7 habits of highly effective people here are the 7 habits of highly effective IT projects:

Habit #1 - Open and trusting culture

I said it before and I say it again: Agile is a state of mind more than anything! Establishing a culture based on openness, honesty, trust and respect encourages efficient communication. Risk and issues are identified and brought to the table where they then can be resolved in collaboration. Goals, risk and outcomes are shared and the team (client and vendor, business and IT) works together to achieve the desired outputs. Individuals embrace responsibility and accountability for their actions and for the success of the project.

Habit #2 - Identify your stakeholders

Find out who your stakeholders are and divide them into three categories:

• The ones that can stop the project - typically your project sponsor but there may be more
• The ones that can delay your project - dependencies to other people/projects, political agendas etc
• The ones that are interested in your project - they need/should be kept in the loop but do not have the power to impact the project

Failing to engage critical stakeholders from the get go can result in incomplete requirements, a wrong impression of the desired project outcome. Which leads us directly to

Habit #3 - Define success

Ask yourself if you have a clear definition of what success for your project looks like. Sure, there are the obvious things like “on budget/on time/to scope” but can you honestly say that even if you achieve all that your project is successful? What if you deliver everything but it turns out that the scope defined does not fit (anymore) the business requirements? On the other hand what if you do not deliver everything you set out to do but what you deliver is meeting the business needs perfectly?

At Fronde we usually define success with the help of sliders (developed by Rob Thomsett). These sliders show the priorities and the flexibility in certain areas, namely:

• Stakeholder satisfaction: How important is it that all stakeholders are completely satisfied.
• Objectives: Do all objectives have to be met?
• Time: How rigid are the timelines?
• Budget: Is there room for movement under the right conditions?
• Added value: Typically not all objectives add equally value to the business (e.g. compliance requirements)
• Quality: Does the system have to be bullet-proof? Or is there room for defects in lesser used parts of the system?
• Team satisfaction: How important is it to keep the team happy (disgruntled team members might leave)?

The kind of questions that the sliders ask are along the lines of “Is it more important to meet the dead line or to add value to the business?”. Having all stakeholders agree on the priorities and movement in areas is a sure sign of a highly effective project!

Habit #4 - Define scope

Quite often projects define scope as business requirements - in other words features of the system to be built. Effective project management defines scope as explicitly in scope and explicitly out of scope. Everything that needs to happen to make this project successful but is not the responsibility of the project team has to be identified (typical examples are user documentation, training, implementation/roll-out etc). Equally important is to identify one or more stakeholders responsible for making sure these things happen! So every out of scope item has to have a name next to it and this person/these persons take on the responsibility of making it happen (directly or indirectly).

And by the way, once you have defined scope make sure that you manage it efficiently!

Habit #5 - Deliver often and early

Agile comes in many flavors but all of them rely on iterative development techniques. Short (1-4 weeks), time-boxed iterations provide well-defined milestones where small chunks of the overall system are delivered - fully tested and ready for a production release if the business decides so.

The progress reported to the business and end users is quite tangible and stirs thought processes about how fit the current system (built to the current specifications) is for its purpose and gives all stakeholders a chance to rethink the priorities of the features yet to come. Some features may get deferred or dropped at all in an effort to work to an ever changing market - some may just get dropped because they seemed to be a good idea at that time but with a tangible system in front of stakeholders lost their initial charm. New features have a chance to be implemented quickly because the business can prioritize them in at the beginning of each iteration.

Deviations from the intention of a requirement (e.g. a misinterpretation or ambiguities in the specifications) are discovered early on and can be remedied with little cost involved.

Habit #6 - Planning and tracking

Keeping habit #5 in mind there are basically two levels of planning:

1. The project plan: This is the obvious one that most if not all projects have. It defines an overall timeline, major milestones and the road map - the strategic direction of a project or product. This is also the one that is more likely to adapt throughout the project.
2. The iteration plan: Most agile methodologies recommend a half day to a day planning session at the beginning of an iteration. The key here is to break down the features/user stories/use cases into small chunks of work (1-2 days max). This will allow you to track progress in a much more meaningful way. Rather than estimating a task to be 40%/70%/90% completed (and run in surprises in the “last” 10%) a task is either done or not - and with “done” I mean it has been accepted by the testers. On a related note consider spending some time at the beginning of your planning session on a retrospective of the previous iteration.

You can track progress in many ways - e.g. using spreadsheets, web tools or sticky notes. Whatever you use make sure it is visible to the team and ideally the stakeholders. If you are co-located having a board with sticky notes that move from “open” to “in progress” to “in test” to “done” is an easy way to track and communicate progress.

Habit #7 - Tools

Make sure you have the right tools in place to support an agile environment! For a software development project for example, at the bare minimum have an IDE with productivity support (e.g. Refactoring toolset), a source control system that allows you to easily roll back to previous versions and a continuous build server that compiles the code and runs unit tests and some code analysis tools on each check-in. There is no point in embracing change when it takes you ages to execute the change and you live in constant fear of breaking something!