Get agile or die trying
After my long-lasting abstinence of not-networking at various afterwork events with all their intriguing names and topics, I decided (maybe out of repentance or sense of guilt) to give it another try and visit such an event again to undergo a personal sanity check whether I and the way I am handling projects are still contemporary or at least meet the basic needs of an agile approach nowadays.
Anatomy of agile events
First of all I have noticed that at such events you get to meet two different types of people in particular. There are the hypocrites on the one hand and the vacuums on the other hand. The first type visits these events mostly to hate against its topics and best practices since these people broad chestedly convey a feeling of always knowing better based on their profound experience and wisdom, which they are happily showing off while sitting there with nothing but a crooked smile and snooty attitude. On the other hand I came along vacuums. This group of attendants is characterized by their friendly openness towards other people and the contributions along the agenda list, sitting there cribbing with their moleskine notepads (which they most likely got from expensive consultancies while they were introducing agile methodologies or visiting some of the inflated courses to gain points).
In a nutshell: Obviously my abstinence was not long enough. Same faces. Same groups. Same topics. Same Scrum. Same Kanban. Some „new“ phenomena sounding like a disease „SAFe“. Everything same same but unfortunately not different.
In this publication I want to share my path of experience from Scrum to Kanban to the final flow of work I like to use in various projects and my daily work. I hope that I don’t sound like a hypocrite or a vacuum at the end. Keep in mind, every Jack has his Jill, and so do I…
Agile became an industry
Meanwhile „Agile“ has been promoted to a buzzword (such as design thinking a couple of years ago) and can especially be found on the majority of job descriptions circulating in the web right next to its sibling „flat hierarchies“. In the midst of Scrum, Scrumban, Kanban and other candidates, companies and especially their IT departments either started the process of agilizing or are on the way of becoming master Yoda of agile through „Kaizen“ (yes, this calligraphic sign which ends up as a poster on the wall to remind people of continuous improvement).
Also the numerous consultancies and agencies that sprang up like mushrooms out of nowhere offering ultimate best practices & expertise for project management, software development, people management, strategy etc. pp. expose agile as a hot traded product/service. So at the end of the day agile became a multivariate expression with a perspective-dependent definition. A circumstance that often let us forget what agile is really about and what it is definitely not.
Agile is not a process
What I’ve learned in my past couple of years as a product manager is that trying to utilize agile as a process in form of Scrum, Kanban and whatever they are called ends up in producing more waste. Here is why:
Scrum
Being (un-)agile
- Scrum is a process-oriented cover up that brings you waterfall in small bites and pieces. Scrum made me and my team much more un-agile and immobile since the planning process for current and upcoming sprints is time/effort consuming. Also the „definition of done“ is some kind of checklist for an action item that can be just crossed out of a list. And when are you going to validate the results of such an item? Was it a success? Did you reach your goals? Ah sorry no time for that, we already got the next sprint running….
Fitted processes and structures
- Every company, every business case, every team, every vision, every customer group is different. There is no framework/process that can handle and process all these factors and concurrently improve the performance of a unit. So conclusively the company has to tweak and adjust the process with the time resulting in dogmatic discussions about the „correct“ use of Scrum.
Separation through roles
- The classification into concrete roles, responsibilities and abilities kills the team spirit since every single part of a team tries to fulfill the assigned role. Thus leads again to the emphasis of doing the things right and deflects the team from doing the right things such as encouraging in creativity and concentrating unified on the jobs to be done.
High Maintenance
- After some time Scrum feels like a cockpit of an airplane with tons of different knobs and control mechanisms. But still you are in the same plane with the same engine, same people and the effort of keeping this airplane up in the air prevents the team to look out for different opportunities that may have risen during the flight.
WASTE IS ANY HUMAN ACTIVITY WHICH ABSORBS RESOURCES BUT CREATES NO VALUE!
- James P. Womak & Daniel T. Jones
Kanban
Missing Outlook
- Don’t get me wrong, I am a fan of the chaos theory. I like to face undefined problems and try to find solutions while working with a bunch of people. But does Kanban help here to find the right solutions? Or to concentrate on goals? No. It is just about getting shit done. Which is great in some cases and especially for teams that lack efficiency, but it does not help to have clarity and certainty of doing the right things.
Missing knowledge transfer
- Since the team grabs action item after action item it is automatically concentrating on the performance (to become the most productive development team) — it is all about the output. Of course the team is doing pairing and code reviews but real learning and understanding can only be established in a surrounding in which everybody feels responsible for the product which means also dealing with the input, discussing ideas, validating finalized items.
Low-level of team cohesion
- You are sitting in the same room. You are doing stuff that came from one and the same backlog. But still everyone does his thing. Dealing with his/her contextual problems. Here we are really talking about resources and not people anymore.
Take a step back…
What helped me a lot to improve my way of working within the company, understand the needs of a customer, getting traction with team dynamics and allow a flow system with ideas, creativity and validated output was a simple step back. And this step meant for me to internalize once again the agile manifesto, word by word, phrase by phrase which became not only my woking mantra but the way of handling things in the whole team.
- Individuals and Interactions (over processes and tools)
- Working Software (over comprehensive documentation)
- Customer Collaboration (over contract negotiation)
- Responding to change (over following a plan)
Together with my team we set up a guideline for our workflows that was based on the mantra above. As an outcome we finalized 8 simple points that lead us day by day through challenges, problems and crazy (and of course valuable) ideas from stakeholders.
Here is the list:
- Product Development as one team — No separation between IT & Product Management
- Shipping code is just the beginning — ongoing validation of added value to customer/service/product
- Get rid of waste — everything that slows us down is waste
- Before deployment we know all the important KPIs we want to impact and we know possible risks
- Team takes the complete responsibility and accountability for actions
- Setting of concrete goals on daily/weekly/monthly basis
- Focusing on progress
- Learning to say no!
Conclusion
In this publication I tried to sum up my way of finding the right way of working…that works for me. My insights are just my personal and subjective observations that are always dependent on context. Every team, company and person is different. So of course there are examples in which Scrum, Kanban etc. are working.
Getting rid of waste produced by frameworks, stop thinking in processes and focusing on the simple statutes of agile manifesto has helped me on getting one important thing straight, namely getting the right shit done while engaging in a self-regulating setting that fosters creativity, accountability and responsibility.
