Agile projects and project management practices

Panacea for Agile projects?

Mike Cottmeyer recently said Yes, Agile is not Agile Project Management. Indeed, Agile is no project management methodology, though often sold as one. Agile is a developmenet approach which significantly influences the projects are organized and led.
The Agile PMP v2

View more documents from Mike Cottmeyer.

Makes you hungry?
Once you have done or been a member of an Agile project, the next question is often: why haven’t we done this before? And: why wouldn’t we do it on every next project? So, Agile becomes the panacea for on-time delivery and a scope that meets Fitness for purpose / Fitness for use.

Obviously every project faces challenges to its design, management, resources and support. I wouldn’t choose spontaneously for a classic waterfall / linear development. Motivation and employee involvement are much better in an incremental, growing, adjusted result. Cultural elements like take responsibility as a team, put the business at the steering wheel of ICT development really appeal to me.

So, Agile everytime and everywhere?
Taking the panacea metaphore seriously, you get to Dustin Wax that promoted the Scrum for One. In my opinion that’s too much. What do personal effectiveness and efficiency, getting things done habits to do with a team effort like Agile Scrum? Call it purpose driven life/work in private life, a personal development plan, getting things done, or something like that, but not Agile/Scrum. En beware to promote only your personal ‘best practice‘. What’s good for you isn’t necessarily good for the other. Bad examples are Koen van der Borght’s article on GTD. Besides recognition as a guru, also labels like method freak, evangelist, or ‘having a tunnel vision’ can be used.

How do you prove what you believe in?
The apostle Paul defined faith in Hebrews 11 as: “The faith which lays the foundation for everything we hope it convinces us of the truth of what we do not see.” It remains difficult for us, enlightened people that want a proof for everything. A few recent examples from my own environment.

What is the added value of social media?
Most likely background: pastime, hard to sell as a product or service in a time of crisis to an eager client / business executive. And so one relies on social media studies. Mind that the basic approach at social media (web 2.0, social networks and related ‘buzz words’) is collaboration. And while everyone intuitively agrees with the added value of working together, we like to quantify the effects of a business case.

Does Agile really work?
The demonstration at the end of the forst Scrum sprint of 4 weeks really did open the eyes of participants. Yes, it really is possible: working software, including error handling, a database and compliance to the corporate look & feel. And so you meet your late converts, who like the biblical Thomas after another week want a personal demonstration. And again, can you get a grip on a team that has learned to work together? Ok, you can watch a burndown chart, but what does that ‘sign’ mean?

Creationist and evolutionist bury their hatchet
An attractive headline in Nederlands Dagblad about a congress in this Darwin year. Both creationism and evolutionism are beliefs, the author writes. A week earlier, ‘a large and diverse group of christians’ signed the Declaration of a common belief in God as Creator. And so, this was legitimate ground for satire at Goedgelovig.nl: the Creator and his fearful followers. Can you prove your faith with a signature? Is that necessary? A small step further you get to the link between Genesis 1 and Pangaea as KingdomGeek ‘proved’ lately.

No faith without evidence
Pé de Bruin, who passed in January 2009, wrote among other books Geen geloof zonder bewijs (No faith without evidence). The founder of the Utrechtse Stadsblad wanted to know why he lost two of his children, and decided to study the Bible. He didn’t see value of a theological study. He wasn’t really interested in what others wrote about the Bible. He wanted to read it himself, back to the source.

Agile project management: daily insights
Many project managers are split between line managers that want weekly huge reports and insufficient means like time reporting systems and processes that involve (too) many steps. Is it useful, even possible, to manage time and money? Add to that constantly missing data like estimates to complete (ETC’s) and modifications of hourly rates throughout the project lifecycle. Monthly reporting is becoming a necessary day alone with project management software, calculator and issue log capture the movements compared to the planning.

It can be different!
How different is the transparancy of Jira’s Greenhopper extension. On a daily basis you can measure the project team’s progress. And it’s tranaparent not only to you, but to everyone that has access to Atlassian‘s flagship for system development support and test.

With this daily insight it’s possible to take measures like
– remind the team to its commitment to deliver promised results
– accept or withdraw requests for a day off.
– ask for help

Agile project management – estimation and measurement
Prior to the first sprint, developers and software architect estimated the User Stories using Planning Poker. This session was facilitated by the Scrum master. Measurement of progress is done with the GreenHopper plugin on Atlassian‘s JIRA. Important is the burndown chart

But what if the size of a piece of software doesn’t match inititail or perceived weight from a tester’s or designer’s point of view? How useful is it to speak of a team’s productivity by taking only story points per day as measure, even if roles like designer, developer and tester are not interchangeable?

A work-around is to get estimations from each and every role, from both developers, designers and testers. In case sizes differ significantly, e.g. easy to design, moderate effort to develop but very hard to test, one has to plan old-skool, puzzle and move around possibilities:
– available capacity in the roles needed;
– delivery order of individual user stories
Would it have been different when another measure of work size, like smart use cases, used at Capgemini’s Accelerated Delivery Platform? I think there’s no difference, given the lack of information at its disciplines Development (what’s the difference between development, code and deliverable generation anyway?), Testing and Acceptation.
Estimate apart, OK, but commitment of the whole team for the sprint’s content is very important. Important too is team productivity measurement during the sprint. As a project manager I don’t value “who’s to blame” games afterwards.

Agile Project management – a user story
ProjectizedThushara Wijewardena from Sri-Lanka published a series of lessons learned on first experiences with Scrum projects. The story is recognizable, because this relatively new approach with only a few hand books, structures, best practices, etc. requires tailor made adaptions on a real project. And that’s the case with every method, approach or structure needed to support or design a process. It can never be done by literally following the rules of the text book, taking serious all rumours or assumptions. Always be smart and practical. Use your brains. Two topics draw my attention, since I’m in the process now of tailoring the Scrum approach: specifications and tests.

Specifications: which and for whom?
During the Startup stage one has thought about requirements, necessary system functions, by the book. Contrary to other project approaches the requirements isn’t fixed at all. No, the Scrum approach explicitly takes scope change into account. Nope, it’s not a mandate for free and harmless altering everything agreed upon. Priorities are weighed. Time is money. Everything you do now to realise one thing, can’t be spent to realise anything else. And whether you use SMART requirements, smart use cases or user stories to capture requirements, isn’t worth any war on methods.

What’s interesting from a project manager’s point of view:
1. efficiency while capturing requirements (once, clear, traceable)
2. portability to maintenance functions.
3. a friendly match of approach, tools and personal skills.

Testen in agile projects: who accepts what and when?
Agile testing within a sprint is quite common. It’s the reason why testers join the Scrum team from day 1. Scrum gives a series of tools, hints and practices for unit and (parts of) system tests. Only recently some attention is paid to functional tests and user acceptance tests. Two books featured here, Agile Testing and Testen 2.0 (Dutch) help my team to make up a Master Test Plan based on the Definition of Done via a (product) risk analysis. The test strategy is focused on testing the delivered functions during the monthly sprints. The demo on the last day of every sprint is used to get user acceptance of the delivered software.
You don’t want to lose that results by a regular long period of traditional user acceptance tests. Quite often such a period is an open door for scope extensions, wishes and conflicts.

If you have the time, please spend an hour on this Google TechTalk presentation by Quality Tree‘s Elisabeth Hendrickson on Agile testing.

Upon request of a UK colleague I translated my blog post series on Agile, originally posted in Dutch in 2009.