Agile and Scrum are some really handy buzz words. A buzz word can be defined as a “…term of art or technical jargon that has begun to see use in a wider society outside of its originally narrow technical context by non-specialists who use the term vaguely or imprecisely…” (as stated in Wikipedia).
As a consultant I get the benefit of working in different environments and working with different methodologies across various industries. I've had the benefits of seeing highly skilled and motivated people impress upon me the ideals of a good working methodology to only then butcher the implementation of it in practice.
In almost all of the projects I’ve been involved with that stated they were either Agile or following a Scrum methodology were merely using buzz words to sound impressive. I’m not easily impressed.
Agile is not Scrum. Scrum is Agile. There are many implementations of the Agile methodology, Scrum is just one such implementation. There is Lean, TDD, eXtreme Programming (XP) and the list goes on and on. Agile means an iterative development where requirements and solution evolve through collaboration between self-organising cross functional teams. Essentially that the scope of work is not fixed. It is continuously reviewed and re-prioritised based on collaboration between the Client and the Vendor. You may here terms such as Product Owner and SCRUM Master blah blah blah.
Anymore buzz words? If the terminology has not been clearly defined before you use it, then it is a buzz word and either you don’t understand it, or the person you are stating it to does not understand it. Assume nothing.
More often than not projects fail to factor in how much the client affects the implementation of that methodology. Take for example the Waterfall methodology. Before you stop reading, I'm not about to suggest that this is good practice, there's a point coming. Waterfall is quite simple, it is not confused, misconstrued, misinterpreted... If someone was to say they were implementing a Waterfall project, you know straight away what it entails: heavy initial documentation; development of some type; UAT; and project completion. Simple, might not be that effective, but that’s for someone else’s blog.
If someone was to say they were following an Agile methodology and implementing a Scrum project, we might each of us have a difference of opinion on how this project would be implemented. The client would have a view, the Project Management Office (PMO) would have a view, and the development team would have a view. Those views might well be very different.
This is where I believe the process gets bogged down. People know the buzz word; they don't often know the definition. Very few people will say they don't know Agile, or they don't know Scrum in the city where I'm from. Seems everyone knows it. Great. Define it for me.
Maybe you come across someone that may have read the Agile Manifesto. Well done, but does that mean you understand what makes a successful implementation of it? Maybe, maybe not. The manifesto is a high level set of principles, it is not a definition.
If I am going to implement a methodology in to an organisation successfully, then it needs to be defined accurately. It needs to be defined in a way that the Client understands what it is they will get out of it (ROI) and how the project will be delivered (artefacts). Very few projects I have worked on do this, or do this well. The Client hears the buzz word, they are smart, we are smart, let's move on and we can argue at the end of the project when it is time to pay up!?
Take the time to go over each step of the process, even if it means making them listen to something they already know. What it will do is ensure that you, the Vendor, and they, the Client, are talking the same language. Not in principle, but in practice. We will do X, followed by Y, followed by Z in a continuous pattern and deliver you BLAH. If they have any questions, queries, concerns, it gets ironed out straight away, rather than when it is time to pay.
Agile does not mean: no documentation. It does not forsake planning and envisioning. These are still key and critical parts of the process. They ensure that there is a plan, a vision and later determine the Product Backlog. The Product Backlog is the high level plan of what is being delivered at a point in time. This should be continuously revised.
Back to documentation. How much is enough? How much is too much? Where do you draw the line with documentation? I was at a recent presentation from Dave Thomas and I asked the question of where this line is. His answer was simple, between 10-15% of the overall project length. He also phrased it in his slides as: “… to understand enough of the vision of ‘tomorrow’…”
So how do we get this vision of tomorrow? In Agile speak it comes down to:
• Define the Problem;
• Define the person affected by the problem (Persona);
• Describe the problem succinctly (Stories);
• Define the criteria of User Acceptance (Acceptance Criteria).
Defining the problem should include evidence that the problem exists. This will also assist later when we attempt to define the criteria for acceptance.
Each Persona described should have a definition of that Persona (description of their role and background information such as education) so that everyone is aware of the type of person the solution is to be aimed at.
Documentation shouldn’t just stop at “Envisioning” as Dave Thomas so eloquently called this process, he went on to suggest that this stage include common tasks such as: GUI Architecture and Design concepts (layouts; navigation etc); GUI Prototyping; Software Architecture (structure of new, changes to existing); Buy vs Build Evaluation; Product vision roadmap; Paper prototypes describing the final output; Wireframes and interface concepts; System architecture diagrams and models; Proof of Concept software; Return on Investment strategy…
I’m not going to plagiarise everything he went on to say, but as you can see, there’s a lot of documentation that he sees as essential to a successful implementation of an Agile project. It’s not just roll the sleeves up and start coding or delivering output.
Agile works. It works well. But like anything, it only works when all the parties involved have the same understanding. You, the Vendor, understand what the Client wants, and they, the Client, understand how they are going to get what they want.
The agreement between what the Client wanted, and what you delivered is in the Acceptance Criteria. Quite often you get to the finish line and go live, and the end users see the deliverable for the first time and what they expected wasn’t what you delivered. They expected an iPod, but we delivered a radio! They expected a laptop, but we delivered a desktop!
Even in Agile projects, especially in poorly implemented projects, this is a common occurrence. This is not just something that happens in Waterfall projects. In the typical projects that I seem to be involved with it is either: poor or lack of planning at the start (Scrum implementation); or too much planning at the start and the scope should have changed but remained static (Waterfall implementation).
Take the time to develop a clear vision of what the Client wants. Measure that in terms of how it will be accepted. Revisit the Vision and the Acceptance Criteria after each iteration to ensure that the vision is still accurate. Everything that is going to be delivered should have an accompanying Acceptance Criteria. Nothing should be considered completed until the Client accepts that the criteria have been met. The Acceptance Criteria should be a collaboration between the Client and the Vendor so that both sides understand the meaning of completed.
There are a lot of opinions on which implementation of Agile is a good one, or whether Agile is a good methodology to follow. What I think makes sense, is that whichever methodology you choose to follow, that you, the Vendor, and they, the Client, are on the same page. That you both understand fully the process of how the project is going to be delivered, and most importantly, there is an understanding of how the project will be measured as completed.
