Agile is a buzz-word nowadays. It is used to explain hoteling workstations in an office. It is used to describe management styles. It is used as the catch all for leaders and team members to justify all kinds of requests and projects.
This must stop.
What is “Agile” Anyway?
In a previous post about the Being and Doing of Agile, I described Agile. The gist: Agile is a collection of values and principles that directly inform and integrate with a set of frameworks and tools.
Common Missteps in Implementing an Agile Framework
- Agile is considered a project management approach like the most common one from the PMI. It is seen as a collection of meetings, roles, tools and techniques that can be chosen like on would for a cafeteria – pick whatever you want and it will be a good plate of food. Not true – many Agile implementations fail because of this falsehood.
- Agile is a fad that is based on some values. It is viewed as just another leadership trend that all the “innovative” organizations are using so our company should as well. Not true – choosing to implement Agile needs to be carefully considered and handled with great care.
- Any Agile tool or framework will work. It is seen as one size fits all or (worse), all sizes fit one. Not true – depending on your situation, cultural landscape, and appetite for change choosing the right mix of Agile practices and tools is critical.
Let’s Examine Choosing the Right Mix of Agile
First, it is important to understand why your team or your organization is considering using an Agile approach. Some questions to answer…
- What problem are you facing that your “traditional” approach or framework will be ineffective?
- Why do you believe that an Agile approach will support your change or goal?
- Who else is open to and committed to giving an Agile approach a fair and substantial attempt?
Once, you have determined that an Agile approach is a great choice then it is critical to determine the right mix of frameworks, practices, techniques and tools would be best suited for your goals.
Matching Your Needs to Agile Frameworks
Often organizations will choose a popular or common Agile approach when it is usually better to match the tool to the right need. For example, one wouldn’t say that their preferred tool is a wrench and then proceed to hit a nail with it. Instead, we would assess the situation (needing to put a nail in a wall) and then choose the appropriate tool (a hammer).
So with a transformation or big change it would be better to assess the organization’s current situation & needs, then choose the appropriate Agile framework such as Scrum or Extreme Programming (XP) coupled, if needed, with tools and techniques such as Story Mapping or Kanban Boards.
Let’s begin with Scrum.
Why? Because it is the most common AND the most poorly implemented of the Agile frameworks. Officially from the Scrum Guide, Scrum is made up of 3 roles (Scrum Master, Product Owner, and Development Team), 5 events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), and 3 artifacts (Product Backlog, Sprint Backlog, and Increment). Scrum is perfect for…
- Software development projects or programs that have changing requirements
- Complex work needing multiple disciplines and skills
- Industries facing changing markets and challenging competition within development of products or software
- Organizations that need to make a more intense or dramatic change in their culture or structure to be successful
If one or more of these and other elements exist that Scrum would be a good candidate as the Agile framework for the transformation. However, if none or maybe only exist then it would be better to consider something else.
TIPS for doing Scrum well: (1) Do your research about Scrum. (2) Collaborate with a trusted Agile advisor. (3) Build excitement and interest with others before implementing Scrum.
Let’s continue with Kanban.
Why? Because it is the lightest of the Agile frameworks, it is quite popular, it is the fastest growing method, and it is closely connected to Lean. From the creator, David J. Anderson, Kanban is made up of Three Foundational Principles: (1) Start with what you do now, (2) Agree to pursue incremental, evolutionary change, and (3) Respect the current process, roles, responsibilities & titles. Then build on this understanding with the Five Core Properties:
- Visualize the workflow
- Limit W.I.P. (work in process)
- Manage Flow
- Make Process Policies Explicit
- Improve Collaboratively (using models & the scientific method)
Kanban is perfect for…
- Complex systems or processes that require (not just follow) long lead times in weeks and months
- Organizations that desire small, regular and incremental changes to their structure or processes
- Hardware or intricate product or software that needs to be improved through longer periods of time
Like Scrum, choose to use Kanban if you have more than one of the above elements. Read more about Kanban by reading a great article by David J. Anderson on the principles and properties. Or it might be wise to consider another approach.
TIPS for doing Kanban well: (1) Do your research about Kanban – read material from David J. Anderson. (2) Get support from an experienced coach. (3) Identify a small group to start first.
A great book to learn more about Scrum and Kanban is entitled “Kanban and Scrum: Making the Most of Both” by Henrik Kniberg and Mattias Skarin (which is free thru InfoQ. Another great book is “Kanban: Successful Evolutionary Change for Your Technology Business” by David J. Anderson which can be found on Amazon and other vendors.
Let’s dive into Extreme Programming.
Why? Because this is one of the more popular Agile frameworks and it is more intense than both Scrum and Kanban. Extreme Programming (aka XP) has Five Values: (1) Simplicity, (2) Communication, (3) Feedback, (4) Respect, and (5) Courage.
XP also has many rules within five areas, including:
- Planing (user stories, release planning, etc.)
- Managing (open workspace, sustainable pace, etc.)
- Designing (simplicity, CRC cards, etc.)
- Coding (standards, pair programming, etc.)
- Testing (unit test, acceptance tests, etc.)
Extreme Programming is perfect for any software development project.
XP requires another level of support from both the team members, middle management, and executive management. It requires much more discipline and investment to get the desired qualitative and quantitative benefits. Read a whole lot more about XP through Don Wells’ website.
TIPS for doing XP well: (1) Read about this framework from the creators – start with Don Wells. (2) Connect with experienced practitioners and coaches. (3) Be patient with yourself as this framework calls for an overhaul of how we develop software as professionals.
Let’s end with OpenAgile.
Why? Because this is one of the newer Agile frameworks and it is built on some amazing core values. OpenAgile has three values (Truthfulness: “Truthfulness is the foundation of all human virtues”, Consultative Decision-Making: to take coherent action based on a unified vision, and Systematic Learning: purposeful and meaningful focus on learning), one guiding pivot (The Learning Circle: planning – action – reflection – learning), four practices (Goals, Work in Cycles, Value Drivers, and Tasks), two events (Engagement Meeting, and Progress Meeting), one role (Team Member), and five supporting paths of service (Growth Facilitation, Process Facilitation, Tutoring, Mentoring, and Catalyst).
OpenAgile is perfect for…
- Leadership teams wanting to be an example of Agile being and doing
- Staff teams that interested in an Agile framework that is both simple in its application and not overly complex in its structure
- Groups that are interested in using an Agile framework that places, even more, emphasis on team coherence that Scrum or XP
- Groups that are excited about doing Agile but lack the freedom or authority to completely change their framework
OpenAgile requires an acknowledgment that human beings are inherently valuable and that working together without focusing on ego is powerful and effective.
TIPS for doing OpenAgile well: (1) Do your research about OpenAgile. (2) Get support from a skilled mentor or coach who has done OpenAgile. (3) Help leadership to understand both the uniqueness and creativity that OpenAgile enables.
A great place to learn more about OpenAgile is at the official site: www.OpenAgile.com, and I strongly recommend that you read the OpenAgile Primer. Full disclosure: I am one of the creators of OpenAgile with a few others, and I am on the board of directors.
What have I missed? What have you learned from using Scrum, Kanban, Extreme Programming, or OpenAgile? What other pieces are needed to be present in a group or organization before choosing each of the Agile frameworks? If any good suggestions are stated in the comments, I will update my article.
Keep in mind, that any change (especially an Agile transformation) is hard. And it takes plenty of support during the many months and years to keep it moving and advancing.