What is Agile?
About 70% of projects fail. Most of these – a vast majority – still use the Waterfall methodology. Waterfall is completely unsuited to building software, code, systems or complexity of any variety. Why do firms still use it? The answer is that most organisations are populated by control-freaks who feel that micro-management is the key to success. The attributes of Waterfall, by its inherent illogical nature, usually ensure failure.
Agile is the opposite of Waterfall, meaning that it is based on common-sense. Agile is an approach based on integrated (client-vendor, inter-functional) team-work. The team is King, not a control chart. Project agility is the opposite of the top-down (totalitarian) mind-set that has dominated projects since WW2. Previous to WW2, innovations were premised on agility and fast-fail. Domain experts (or singular- an expert), would attempt to solve problems (the key reason to have a business), through rapid failure. Concepts would be tried ranging from the incremental to the entirely novel and innovative. Ideas from anyone involved in the process would be used regardless of rank, pay position, or accreditation. The best idea was implemented and the team would move on to the next challenge.
WW2 demolished the ideas of fast-fail, self-organization and cross-functional team-work. If the government and its massive top-down bureaucracy could win wars, then the same model could implement projects in the business world. This gate-stage-Waterfall theology is in the main, the enemy of fast innovation. It seeks to control all aspects of a project and marry complexity to simplistic GANTT or Milestone assessments. In reality, the use of GANTT and other control mechanisms are usually divorced from reality and project detail. A project manager mapping to a contractual milestone plan will initiate complex GANTT descriptions, without bothering to ask Technical experts if any of it makes sense. He or she then reports it to their supervisor, who then ushers it to the manager, who then translates it for the Director, who then further interprets it for the sponsor…..
This inane chain distorts reality. Most projects based around artificial Waterfall control creations are imposed on teams who do the actual work. The result is an impedance mis-match between what the engineers know can be done and when; and that of the control-freaks in a centralized Programme Office. Oftentimes a project is declared to have ‘failed’ because the disturbed measurement systems of GANTT and Waterfall have not been reproduced in reality. The fact that no-one bothered to ask people who do the work their opinion is never entertained as an explanation of the ‘failure’.
When do I use Agile?
Whenever you are building anything from a paper airplane to a space station. Agile best practices:
- -Small teams of 6-9 members
- -Cross functional
- -No Project Manager input – they can observe and take notes
- -Requirements are vague or ill-defined
- -Target platform is vague or ill-defined
- -There is cross-team collaboration with the client
- -You want results not paper
Agile’s Basic Roadmap:
The team and project structure of Agile follows a basic Roadmap. Within Agile-Scrum this ‘Roadmap to Value’ is a high-level view of a project. The diagram below summarizes:
(Scrum.org)
It does not matter what you call items or phases, as long as the dictionary is commonly understand amongst the team. There are 4 common entry points as given in the figure below.
You should amend the above to make the process as simple and as straightforward as possible. For example, you can use online tools to capture requirements-design and your statement of work, accessible to the entire team. You make a Statement of Work or SOW, sometimes called a Project Design Doc (PDD). This is the ‘product roadmap’ in the above figure (note, Agile is not just about building software products). The tasks to complete the PDD or SOW are called the ‘backlog’ within Agile.
Your ‘backlog’ is what you need to do within 2-4 weeks to complete (part of, or all of), the project. These backlog tasks are assigned to human beings called engineers. Nothing is abstract. Your daily ‘Scrum’ or meeting is simply a review of what has been done, what you/we are doing today and what needs to be done this week. It also reviews if we are on, or off-schedule.
The information from Scrums and Agile teams can be fed back into a Project Manager. Minutes and decisions are recorded. Documentation is important but only the essential is completed and committed. There are no GANTT or totalitarian artefacts. If Project Managers need to build GANTT’s they are free to do so without disrupting the Agile team. The Project Managers do not run the teams and they do not run the projects, and they don’t give technical advice or solutions. The team is self-managing, self-contained, and will ask for help when needed. For example change requests need to follow a process to assess, approve and budget.
Key stages within Agile:
Project planning: The first phase is the SOW, or Project Design, based on requirements. Agile is iterative, these designs and solutions might be (will be), changed during a period of time as you discover and elicit precise requirements and what the target platform will look like. This planning includes getting the right engineering skill sets together on the team to implement the project. It also includes identifying the Product Owner (from the client), Subject Matter Experts (SMEs) and Technical Team Leader(s). The Technical Team Lead is responsible for the team and its success. The team is composed of engineers, SMEs, and a Product Owner. Smaller the team, the better. It is a myth that saturating a project with many headcount will lead to success. The opposite is true.
Release planning: A release is a phased approach to deploying a solution. It might entail some general milestones and objectives between the start of the project and its end. It could include for exampole, future product features or platform improvements as well. In the real world, you focus on Release 1.0, stabilize that system or product and then make a release plan for version 2.0. Release planning for 1.0 is part of the SOW or Project design.
Sprint: This is taking the entire project and breaking it down into pieces and short cycles of development. Instead of building complex systems in their entirety over a long period of time, we break the project down into shorter cycles of functionality, that we can test and prove. These are the iterations of technology development. Sprints can range from 1 to 4 weeks depending on the project.
Sprint planning: This can be embedded in the SOW or Project Design Doc, and is reviewed every day in the Scrum session.
Daily scrum: Usually this lasts about 30 minutes and involves the entire team. Each member contributes what they did the previous day, what they are doing today, any obstacles they need to overcome, or desired help on an issue. It is not a whining-moaning session.
Sprint review: At the end of an iteration deliverable or ‘sprint’, there is a general meeting of the team to review the functionality delivered, best practices, lessons learned and improvements for the future. It is not a whining-moaning session.
That is about all there is to it. The above Agile approach is also called ‘DevOps’. Development-Operations-Testing are combined within the team. It is self-contained. In reference to team management where you store the information (SVN, TRAC, Jira, your mother’s cookie jar) is up to you. How you record the information is up to you. How you overcome obstacles and achieve success is up to you and the team. Agile is liberating. Keep it simple. Every team will use Agile in a different way. What counts are results. Not GANTT charts.