Thinking a project through before kicking it off is valuable. Being able to communicate this thinking to others is imperative. To get funding; to share the vision with the team; to inform other stakeholders about the goals of the project. So next time you need to do a more formal project initiation, why not try it in a format that's more appropriate for the purpose? Kelly.
I've written before about how I think Agile Project Management alone is not enough. Project Initiation is one of the areas of agile methods that I think needs embelishment for large projects.
Over the years, I've used quite a few techniques for project initiation.
But I've never really come across an agile one.
My first experience of formal project initiation was a Project Definition Report in Method1, a very traditional methodology from Anderson Consulting as they were known then; now Accenture.
Then, as a Project Manager, I used a PID (Project Initiation Document) from the PRINCE2 project management methodology, which I guess is probably the most widely used today.
In MSF (Microsoft Solutions Framework), there's the Vision & Scope document.
Truth is, they're all pretty similar really. Long documents, with lots of details about a project and how it's going to be run. Long, tedious documents.
Yet, for large projects, they are important.
As a Project Manager, I always found the thought process they made me go through was incredibly useful. I personally benefited from writing them; that's for sure. Without them, the project could be poorly thought through. And the chances of failure would certainly be higher.
So the thinking was valuable. Trouble was, no-one wanted to read those lengthy documents. All that thinking. All that writing! And no-one was really interested, truth be known. Not the Project Board. Not the project team. And certainly not the wider stakeholders.
So, if the thinking is valuable, what do agile methods have to offer instead?
Nothing.
Unless I've missed it somehow. Nothing.
So, for large projects that warrant it, how do we incorporate this valuable thinking into agile methods? And how do we do it in a way that people will actually pay any attention to?
The answer is simple.
Do it in PowerPoint.
Producing this information in PowerPoint has some profound effects:
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Agile Project Initiation
Computer Weekly Blog Awards
 |
| Nominate me in IT project mangement |
 |
If you like my blog, why not vote for me in the Computer Weekly blog awards?!
I've been shortlisted in the project management category. So if you want to make sure agile software development is properly represented in this category, vote for 'All About Agile' now :-)
Click on the badge above to vote. It'll only take you a moment!
Many thanks in advance for your support...
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Scaling Agile Software Development
Check out the above video. It's an interview with Mike Cohn (about 10 minutes long). In this interview, Mike talks about scaling agile across the enterprise, on projects as large as 700 people!
Mike is the author of the popular books, Agile Estimating & Planning and User Stories Applied. Personally I particularly like the User Stories Applied book. I've written quite a few blog posts about Writing Good User Stories. They are so simple, yet so empowering.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
State of Agile Development - 3rd Annual Survey
It's that time of year again. The 3rd 'State of Agile Development' Annual Survey has now been launched.
This is not a vendor or tool survey, it is meant as a global survey on the general state of Agile development - hence the catchy name!
Last year the survey received 1,700 completed surveys from 71 countries.
The results from past surveys have been written up in publications ranging from CIO Magazine to InfoQ to SDTimes and the Agile Journal. The results will be released August 4th at Agile 2008 in Toronto, and also e-mailed directly to participants.
Find out more and take the survey here.
It should take 5 - 10 minutes to complete and your participation is greatly appreciated.
What do you get for participating? By contributing and sharing data anonymously, you will help create the largest data collection on the value of Agile development practices and have direct access to the aggregated results. We are also giving away participation prizes consisting of 3 Amazon.com gift certificates totaling $1,250.00.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Putting the *Analyst* into Test Analyst
For years, I've given Software Testers in my teams the official job title of Test Analyst, or something along those lines.
Yet (informally) I've always referred to them as Testers.
Only in more recent years - and especially since adopting Agile Software Development and User Stories - have I really discovered how to put the *Analyst* into Test Analyst.
I've written before about 'Why Agile Testers Should Be Involved From The Start'. It's obviously very important in agile development, and has a number of very good benefits.
With User Stories, we've gone a step further.
A Business Analyst, Product Manager, Product Owner and/or the Team should identify the relevant User Stories for the Product Backlog. From this feature list, for the selected items for the next Sprint, requirements need to be clarified and expanded on.
The requirements for each User Story should be discussed and clarified as a team. But, in my view, the Test Analyst is an ideal person to lead this discussion and write up the User Story cards.
Test Analysts tend to be very analytical in their nature. They tend to be good communicators. And, as we all know, they can think of scenarios that business people and developers never even dream of! :-)
Moreso, when it comes to writing test cases on the back of the User Story card, they are obviously the ideal person to do this. Writing these test cases up-front, when the feature is being defined, helps to improve quality from the outset, as developers are more likely to write their code to pass the tests (because they know what they are).
But also, it makes perfect sense to me, for the person that's going to test a User Story, to be the person that defined it.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by p0psicle
