Not just coders

I have spent the last few days hiding from cable news.  The death of the Queen of England and the mourning and celebration it generates is overwhelming.  I have spent my time reading David Forster Wallace's essays and working on white papers focusing on creating cross-functional teams.  It has been a welcome respite.  As I was writing, I stumbled upon some online forums discussing the role of developers in an agile team, and I felt that I needed to make an important point.   

I have commented on the attitude of a minority of people in the project management profession that the only role of a development team is to write code.  It is an incorrect assertion.  A development team not only includes people who write software code but quality professionals, data specialists, user interface professionals, and business analysts.  Each team member has a say in delivering value to a customer.  The combination of these diverse skills makes an agile team so powerful.  

Leaders with command and control mindsets think that developers are interchangeable.  A developer understands a computer language and can take business requirements and translate them into that language.  What these leaders do not understand is that developers are people.  Developers have children and spouses.  Like all human beings, they are struggling with emotional and existential challenges.  Software developers deal with deadline pressure and problem-solving differently than others because each is unique.  A software developer is not some nameless worker bee working for the company hive; they are flesh and blood struggling to get along in the world just like everyone else.    

Along with Marx's observation that work alienates people from themselves, I believe the dehumanization of people keeping the global economy spinning is the biggest challenge of our time.  People should take pride in what they do, and saying a software developer is just a coder dismisses all the intelligence and effort they put into mastering their craft.  Influential bureaucratic organizations often make the work process impersonal and anonymous, whether in government or business.  

A competent software developer requires creativity, attention to detail, intelligence, and the ability to deal with oppressive levels of frustration and doubt.  The middle ground of healthy self-esteem is elusive when you are on deadline with a gnarly problem to solve.  Some days you feel like the dumbest person on the planet, and other days you want to revel in your intelligence.  It is emotionally taxing, and treating these people like mindless drones is insulting.  

Treating people like people instead of nameless cogs in a global machine is the key to success in a global economy.  I have come up the technology ranks as a hobbyist, student, entry-level developer, and finally, a scrum master.  This experience in the trench of software development makes me a better leader and agile coach.  

Until next time. 

Fight Bad Agile!

Command and control did not
 work then and it will not work now.  

I have been involved in the agile reformation for the last ten years.  In 2009, the agile manifesto was relatively young, and it was a quirky idea to make software better. Today we have three primary scaling techniques for agile.  The reformation has grown and splintered over the years, but the manifesto remains the pole star which every variation circles.  Now business professionals and executives are paying attention to the reformation.  Agile is eating the world, but instead of confronting opposition, we are dealing with corruption caused by the status quo as it exists in many companies.  The corruption creates bad agile, and it is up to coaches and scrum masters to call it out.

Last week, I pointed out that a common dysfunction in organizations is leadership spends too much time pleasing superiors rather than doing the necessary work to make the business successful.  The behavior hurts collaboration between departments and categorizes people as resources which can be swapped out like machine parts.  It is dehumanizing and alienating.  Agile helps fight this dysfunction with emphasis on cross-functional teams and less organizational friction.  The challenge of agile is it works well in the realm of the team, but as it attempts to scale out to the organization, it butts against status-quo thinking, entrenched political agendas, and the command and control mindset of most executives.

Put yourself in the shoes of a typical executive who has spent ten, fifteen, or twenty years in an organization. The executive has presided over budgets and deadlines.  The contact they have with the people doing the actual work is limited, and their knowledge of project management is slight, so they hire project managers to handle the responsibility.  Most of the time, executives spend time involved with pleasing superiors and political sparring with rivals.  An agile coach comes along who tells them they have the wrong career focus, and they have been leading their people incorrectly.  Agile, with its emphasis on inspection, adaption, and transparency, undermines political infighting within an organization, which means career advancement depends on results instead of deception.  It is going to create anxiety, and the executive is going to push back.

The executive is not evil in this instance; the new way of doing things creates uncertainty and fear.  It is natural they would be resistant when confronted with this upsetting of psychological safety.  As a coach, it is going to be your responsibility to address the resistance.  You are going to walk the executive through the process of shifting from a command and control mindset to an agile mindset.  It will not be easy.

Instead of telling people what to do, the scrum master will have to show them.  Lead by example, give the team what they need to succeed, live the agile manifesto and principles, and point out organizations friction where it exists.  Inspection, adaption, and transparency are designed to hold everyone accountable particularly executives.

Bad agile happens because self-interest and the status quo are more important than getting work done.  We tolerate double standards, and it creates corruption.  It is up to each scrum master or coach to reveal this corruption so we can mitigate its effects.  It is up to each of us to show instead of telling others what to do.  Finally, we need to create psychological safety among leaders if they are to embrace agile.  Otherwise, we remain stuck with bad agile.

Until next time.

Don't be a Mad Hatter Agile Shop!

Delivery of software is not madness.

Becoming a scrum master is not hard. Professional certification takes two days of classroom training and a simple test makes sure you understood the information.  The real work happens when you are beginning your servant leadership of a software development project.  You wear multiple hats.  Somedays, a scrum master is a therapist.  On other days, they act as a cheerleader and on others they are a technical consultant.  It is a challenging career.  One of the things which get lost is the purpose of agile and scrum; is the team is responsible for delivering software.  Today, I want to discuss software delivery.

The Agile Manifesto is very clear about delivering software.  An agilest prefers working software over comprehensive documentation.  When the manifesto says “working software,” it means software in production used by customers.  Anything which does not meet this goal is not working software.

Over my career, I have had numerous conversations about when work is done.  Many of these conversations sound like sections of Lewis Caroll’s “Alice in Wonderland.”  I had a developer tell me with a straight face the code was finished, but the code did not compile.  I had another developer tell me they did not need to write unit tests before checking in code to source control.  The worst moment in software development is when a developer says, “It works on my machine, so it is done.”

None of these situations qualify as working software.  As a scrum master, you need to ensure that everyone understands what working software is.  In the agile community, we call what constitutes working software as a "definition of done."  In the medical community, successful treatment of illness is called the "standard of care."  I prefer to use the medical term standard of care when talking about working software.  It is a set of necessary and sufficient conditions.  Here is my formulation of what a good standard of care for web development is:

1. Does the software compile?
2. Does the software have a unit test to prove it is doing what it is supposed to do?
3. Does the software exist in a source control environment so that others can inspect and edit it?
4. Does the software work on a staging or test environment?
5. Does the business approve of the software delivered?
6. Does the software work in a production environment?
7. Are customers using the software?

We do not have working software if these conditions are missing.

I understand the standard of care seems extreme to some but think of all the steps you have to go through when you have surgery.  The nurses are required to count every piece of gauze, and surgical instrument used. The last thing a patient needs is a piece of gauze left in their body to be an environment for infection.  Likewise, in the software world, you do not want to deploy code which is not unit tested because it will be harder to debug and troubleshoot when something goes wrong.

Software not being used by the customer in production is not working software, and any good scrum master and product owner must make sure that happens.  If not, you are just pretending to be agile.

Until next time.

Working with Kanban

Two different ways to be Agile.

When you are working as an agile coach and scrum master you are dealing with innovation at the speed of the internet.  New concepts are constantly coming into being.  It is overwhelming at times.  Luckily, I have plenty of colleagues in the profession who have experience with these ideas when they crop up. 

I was introduced to Kanban when I was training in the Scaled Agile Framework for the enterprise.  I did not think much about it at the time.  It just seemed like a variation on a theme for managing work.  I was wrong.  Kanban is agile, but it is not a subset of Scrum.  It is a different way to meet the principles outlined in the Agile Manifesto. 

For those not familiar with Kanban, I strongly recommend Eric Brechner’s book on the subject, “Agile Project Management with Kanban.” Brecher is not some crazy theorist; he is responsible for the development of the Microsoft Xbox.  In the book, Brecher not only provides basics; he provides the administrative know-how to make it work at your organization.

Unlike scrum which limits work with a timebox known as a sprint; Kanban uses something called WIP limits.  WIP is an acronym for work in progress.  The team can only do so much at a time, so WIP is the limit of that work.  The team then moves work through a queue based on WIP limits.  For example, if the team sets a WIP limit of five for development and a limit of three for QA when work meets the definition of done in development, it is moved over to QA as long as they are working on three or fewer elements.

It is obvious why Kanban would appeal to the “No Estimates,” crowd.  Work breaks down as it moves through the queue and it does not require any estimates.  Scrum rituals like backlog refinement and sprint planning fall away.  Comparing Scrum and Kanban, it is obvious to me that Kanban is well suited to exist in architecture and software applications.  Scrum is perfect for a greenfield project where rapid cycles show stakeholders how the project is evolving.  I am glad that Kanban is another approach in the agile toolbox. 

The agile manifesto says, “Individuals and Interactions over processes or tools.”  Kanban is just another process and tool you can use to help your client achieve agility.

Until next time.