When the Agile movement began in 2001 a group of software developers created values and principles which later formalized into the Agile Manifesto. At the time Agile was created with creating software in mind. However, over the years we have seen the adoption of the Agile mindset and its practices exercised by non-technical development teams. The reason for such an adoption was the increasing need to be able to deliver value incrementally, help teams become more collaborative, and increase the satisfaction of stakeholders.
Recently, I had the pleasure of coaching a non-technical team for a client. It was a fun yet eye opening experience as a coach because it allowed me to coach the minds and work behaviors of a group of eager, and not so easy to win over, professionals to the concept of Agile. The fun challenge with coaching this team is that I had to think differently outside of coaching a software development team. However, while still keeping the principles of Agile, I coached them in ways that made it applicable for their use and continued to gain their confidence in the methodology. Here are some of the key practices that we followed below:
1. Creating a list (or backlog) of prioritized work.
2. Creating UserStories that describe all the units of work necessary to accomplish the items in the backlog
3. Displaying public boards so the team and stakeholders can track progress.
4. Planning out the work to be done in an iteration (sprint), or a set period of time (usually 1-4 weeks).
5. Holding daily 10-15 minute standup meetings where the team checks in on progress and discusses roadblocks.
6. Having retrospective meetings when the iteration is over to discuss what went well, what went wrong, and what could be improved in our team, processes, or products.
The practices as described above were some of the ceremonies that we executed on our team to better understand how to be more agile. One of the most challenging of the myths that I had to destroy within the team was the assumption that Agile was only for software development teams. When in fact that it has many success stories and continue to grow everyday within workspaces outside of software development. Here is an example that is very close to the type of non-technical team that I coached.
How a traditional publisher iteratively developed products with customer feedback
Before I became a software product manager, I worked at a traditional publisher as an editor for a print curriculum product. Our editorial product team applied facets of the Agile practice of continuous development to create and improve our product before and after launch. Every week we developed one week's worth of lessons. Once we had a finished draft, we sent it to a group of alpha testers who used the product with real kids and gave feedback on what worked, and what didn't. We incorporated that feedback and then sent it out to a group of beta testers, who did the same. Even in this traditional print publishing environment, we were able to get a bare-bones version of the product into the hands of users as soon as possible, so we could start gathering feedback on how we could improve it. This helped us identify flaws, and fix them before publication.
(source - TechRepublic)
The great thing about the example above is that it discussed how the team used Agile to get continuous feedback for their teams to continuously improve. We did the same process on my team with a shared feed that we created called "Peer Review". It would allow all members of the team to review items set to be published to give feedback before the final product is submitted.
To be really good at being Agile, one must try to incorporate its practices as much as possible. To show the team that "I practiced more than I preached" I would give them examples on how I would use Agile and create my own sprints for the work I do in my personal life. For example, I create my own personal backlog using the mobile app Trello. I also would break down all of my projects to the smallest attainable piece of work and then prioritize into iterations where I believe it would be best suited for me to complete it within a specific timeframe. The same type of method can be used in other types of work that is outside of software development. Here is an example, of how I use my Trello board to help prioritize my projects weekly.
Unlike the title of this blog article, sometimes Agile CAN NOT BE for Everybody. There are simply some things that Agile can not be applied to, or would be very difficult to do so without some creative coaching and thinking. Project planning for a construction project or infrastructure project for example, are types of projects that have tasks that have a defined sequence, and planned effectively using (in most cases) the Waterfall approach. Waterfall is still a great methodology to use in certain environments and projects. Agile is not a methodology that was meant to replace waterfall. However, it is or has been created to provide a better way of delivering software iteratively and with speed.
The Agile mindset can be applied to software development teams, non-technical teams, and everyday life. From my experience with all three types of working environments, the mindset stays and the result stays the same. Additionally, the end goal is always to create value.
As a developer I used Agile to help create a great product. As a coach, I helped technical and non-technical teams create ways to be more iterative, and change their thinking on how they work. Additionally, as an "Average Joe" completing a task list at home, I use Agile to be efficient with my time while still completing tasks that are of value to me. Agile is For Everybody with few caveats here and there however, I believe it has proven that it will be here to stay for a long time.