I have been an Agile practitioner a very long time, in fact as an Instructional Designer I was very excited when Agile was created based upon Computer Human Interaction methods and thinking. As one complete fully applied process Agile is astoundingly effective at bringing together all the best capabilities within a project team and totally removing the hierarchical and often power crazed notion of single point leadership.

Agile and Structured Business

Agile, however does not remove the need for formal and structured Program Management that interfaces with and supports a more formal set of business processes. I can only say this from experience, if you have managed to get the board, finance, operations or other parts of the business to operate in a true Agile fashion please tell us how you did it. I have now worked on a programme that has attempted this, I’d say we got 40% of what we were looking for. That has to be a caveat thought it has to be true Agile, not some invention of yours that you are calling Agile to cover the fact you have made up your own process.

The Agile Team

When I’m working on an Agile project it’s really important the team is complete during all aspects of the Agile process, at enterprise level that includes;

• User Experience Researchers and Consultants – SM*
• Visual Designers
• Business Analysts – SM*
• UI Developers – SM*
• Backend Developers
• Security Consultants
• Database Administrators
• Enterprise Architects – SM*
• Testing Team

From experience the ScrumMaster – SM* can come from any of these groups. The Scrum Master is an active participant in the project and is not an administration or leadership role. The team leads itself with support from the ScrumMaster. The ScrumMaster also produces non partisan solutions along with everyone else. If the final solution is what the ScrumMaster wanted you have not done an Agile project, just an ego trip for the person with the title ScrumMaster, who is in fact, just an old school project manager.

Agile Planning Poker is a team Exercise

Whenever I join an Agile project my first question to the team is when did you play Planning Poker. This is my first clear indication of how Agile the Agile project really is, I hear answers like “what’s that” or “the planners played it, I think” and I know from that we are all doomed!

You might think that’s a radical response, but Planning Poker is the foundation of Agile, its the point at which the Agile team;

• Discovers the complexities, depth and breath of the project.
• They get an indication of it’s relevance within a program.
• They start to piece together the skills and knowledge of their teammates.
• They begin to establish team thinking.
• They start to understand their relative strengths and role.

It is integral to an Agile project that the team as a whole own the project, everyone is responsible for every aspect, no one throws anything over a wall to another discipline they are all in it together.

Playing Planning Poker can be done is several ways I still opt for the original method with playing cards. Your looking for an assessment of complexity from the perspective of the highly skilled persons technical knowledge. With such a diverse group of people it is rare the get agreement, however doing the first round together is important to expose Trajectory issues.

If you do the first round with everyone in you will get wildly different scores between User Experience, UI Development, Backend Development, Database Administrators and Enterprise Architecture. This is because a simple requirement in one discipline many be extraordinarily complex or even impossible in another area due to existing structures, legacy constraints, timelines or even regulation.

After the first round I separate the groups to find out what they think their score will be. I focus on four key groups who’s timelines can be vastly different and if just pushed together usually causes the project to fail or worse never succeed (we should as a culture look for ways to help people feel successful, happy appreciated people work better and harder) as it was intended, creating a desire to move the goal posts.

• UX includes research, conceptual design and customer testing (absolutely no high fidelity design work is done in UX)
• UI includes visual design and front-end coding
• BE includes backend developers, security consultants, database administrators and testing team
• A is for enterprise architects

Also remember when you get to your sprint planning the reasons for these different responses and be careful to make four sets of cards, working out where the work-stream touch-points will be so they can feed into each other at the right time.

I know plenty of people do this differently save money, save time but produce pretty products that people don’t want to use of can’t use, because the MVP is not viable or it never gets launched in time because the enterprise architect were were involved too late to get regulatory and legal to review and approve the product.

Practical Agile

Ultimately the key aspect for Agile is not the words but the actions and as such it should be part of the education system in syllabus format. Practical Agile should be an educational imperative and afford people of all ages to adopt and use Agile as second nature to achieve both daily tasks and manage complexity.

Summary

I’m not going to do an exhaustive review of Agile here, but the fundamental thing is you can have a Stand Up or a Sit Down to your hearts content but it won’t be Agile. You need to get the basics right play Planning Poker with the entire team to create cohesion, then specialise the Poke to to get viable information. Only when everyone’s skill and experience is involved can you be truly Agile and avoid the awful experience of a Fragile project. Fragile projects are not Agile ones except in name only the process has not been fully applied, easy to spot with people who have created their own version of Agile meaning, Not Agile.

To date my best enactment of Agile was with a .NET team, they were 3 weeks in when I joined, the team was not complete, the requirements were 50% of an A4 page and the budget £1,000,000 on this part of the development alone. The first thing I did was Planning Poker with the available team, around 40% of the final team. I found were dramatically understaffed to deliver in 6 weeks time. I went to the CFO and got a budget release of the extra 50% more staff and a 3 week reprieve to get them before the official start. From official start to completion of a .NET Business Intelligence Toolset working on a 5 day sprint plan was exactly 6 weeks to the completed version 1.0 of the software.

Karl Smith – Scrum Alliance