INVEST in Agile

I have spent much of 2021 working as a product owner.  I receive new insight each day into the role.  I have developed empathy for the people who do the job and the unique pressures they face working on a large-scale project.  I have noticed in my tenure that writing user stories does not appear to be a consistent skill among my peers.  From time to time, when I point out ways to make stories better for the development team, I get testy pushback from my peers.  This time on the blog, I want to cover story writing and the INVEST model.  

Readers of this blog will appreciate that I am a fan of Roman Pichler and his D.E.E.P model, and I have written a few blog posts about the subject over the years.  Lately, I am noticing that some product owners are struggling with the basics of authoring user stories.  I spend plenty of time sharing my blog posts on how to write better stories with my colleagues.  

Lately, some of my peers have asked what makes a good user story, and I did not have a good answer until I learned about the INVEST model.  First proposed by Bill Wake in 2003, the INVEST model has become the gold standard for user stories.  Once I understood its purpose, I became an enthusiastic advocate of its application in story writing.  INVEST is an acronym that stands for; independent, negotiable, valuable, estimable, small, and testable.  Following this model will make your stories better, require less work for the development team, and make like easier for the product owner. 

Independent, when we say a story is independent, it can be worked on individually and not rely on someone outside of the team for completion.  The development team can work on separate user stories in any order.  Finally, if a story does rely on dependencies, it can be easily mitigated with mock data.  User stories should not create constraints or bottlenecks in the overall project.  

A negotiated user story is not a contract or recipe to follow slavishly; instead, it is a conversation.  The product owner and the development team should give and take to know what to build but not how to do it.  In my experience, the most significant area of conflict is when a front-end developer and a UX designer clash over the implementation of a design.  The UX designer often wants the developer to match the graphics file pixel per pixel.  The realities of CSS, HTML, and JavaScript can make that like jamming a square peg into a round hole, so it will require negotiation to get everyone to agree on how the page will look and behave.  

When a story is valuable, it means that its completion will add value to the customer or the project.  The development team or product owner should scrap any user story we cannot explain how it helps a customer or drives revenue for the project.  It is hard to do in hierarchical organizations because the highest-paid person in the room often makes project demands to have work done that delivers no value but satiates their ego.  When in doubt, provide value to the business and customers, the executives will have to pay for their ego gratification with their own money. 

Each story in the backlog should have an estimate.  The team should take time and ask how complexity, risk, effort, or uncertainty surround a story.  It then allows the team to make an educated guess about how long it will take to complete the work.  An estimate is not a quote for work because it may be off. Still, if the team cannot estimate a story, the product owner will need to refine the story further to allow the development team to provide an intelligent estimate.  

Small stories require less time to complete, and these types of stories are easier to understand and provide a swifter path to success.  I talk about the importance of smaller stories here.  

Finally, a user story must be testable.  Suppose you cannot quickly test a user story with either a unit test or easy-to-understand instructions. In that case, the story is overly complex, and it will generate further delays to the project because no one understands what the story is supposed to accomplish.  Keep things simple, and to keep them simple, they should be testable. 

That is the INVEST model.  A user story should be independent, negotiable, valuable, estimable, small, and testable.  Following this rubric will make writing user stories easier and will help get work done more efficiently.  

Until next time. 

Being Grateful is Part of Leadership.

It is Thanksgiving week in the United States, and it is a uniquely American holiday with its origins in the American Civil War.  The family gathers together to have a big meal and make plans for the Christian holiday in December.  The Thanksgiving holiday weekend is also a great opportunity to emotionally reset and take stock of the things in life which make you grateful.  In the lonely world of leadership, gratitude is the only thing that can keep you concentrating on long-range goals. 

General Collin Powell died this year, and this imperfect patriot had plenty of things to say about leadership.  I have plenty of respect for Powell and his style of leadership.  One of the things he says in his book on leadership is being in charge is a lonely activity with others second-guessing decisions.  A leader deals with negativity, hostility, and apathy each day, and it can make even the most enthusiastic to a cause feel crippling levels of exhaustion.  In those moments of fatigue, being grateful for even the most minor things in life make it possible to move on to the next day.  

Even in the dark moments, it helps to take time to show gratitude for what good you can find in the world surrounding you.  First of all, I am grateful to the CAPCO organization.  I was feeling discouraged about my career, and they hired me as a Senior Consultant.  Since I have joined the organization, I feel like I now have a tribe of people as my colleagues.  We are eccentrics, innovative, and want to make a difference in the business world.  Being the lone agile person in an organization is isolating.  To be part of a group of agile professionals going through the same struggles make the fight worth it. 

I am grateful my parents are alive, and I get to enjoy them in their old age.  Life expectancy has doubled in a century, and my family has benefited.  I see my mother and father grow old together.  Our family will spend the Thanksgiving holiday together, and we will catch up and love each other as an immediate family can.  I get to enjoy the wit and wisdom of my parents for a while longer.  

Four years ago, a woman entered my life, and I have been a better person for the experience.  My partner Carol is warm, empathetic, and kind.  She puts up with my crazy career and the emotional ups and downs which come with it.  She is a teacher of young children, so I am learning how to relate better to small children.  She and her grown children have accepted me into their family, and I am grateful for that acceptance.  

I could go on, but I am most grateful for many things.  It helps push away the despair and darkness.  It is a chance to reflect on gratitude which helps make our workday struggles seem less consequential.  I am grateful to you, my readers and I look forward to more agile adventures in the future.  Happy Thanksgiving, everyone.  

Until next time.

Taking Agile One Day at a Time.

The most significant moment in any project is the ribbon cutting or product launch.  It features executives, politicians, and other VIPs cutting a ribbon or giving a splashy PowerPoint presentation before a crowd of adoring fans.  Many people do not understand that those moments of public triumph required many days of sacrifice, frustration, and suffering.  Technology is hard work, and it requires focus, intelligence, and unhealthy levels of concentration.  As an agile coach or scrum master, it is challenging to navigate these long periods of grinding work.  Today, I want to take some time to discuss how an agilist can navigate this period author Lewis Carroll labeled between the idea and reality.  

One of the most important books a technology professional can own is Fred Brooks' "The Mythical Man-Month" it outlines some principles of project management that remain applicable today.  It includes Brooks' Law, which says that late projects become later if you add more people.  Brooks talks about the importance of architecture in software development and how the division of labor between different specialists makes it harder to lead a project.  The most significant insight was the idea that a project falls behind schedule one day at a time for me. 

Each day the team attempts to get its work done.  If you are digging a hole in the ground, the task is straightforward.  Software professionals look at problems that resemble getting square pegs to fit into round holes.  Data from one system must be displayed differently on a mobile device than a web browser while traversing trillions of data points to obtain meaning.  Each day, engineers, developers, and project professionals slog through those problems and more.  It creates pressure that builds over time because many of these problems that need to be solved do not have easy answers. 

Chicago Sports columnist Bob Verdi would joke weekly when football injury reports were published.  A famous player often is listed as day-to-day.  With a comical tone, Verdi would tell his radio audience, "… aren't we all." As technology professionals, we are all living day to day, solving problems and building solutions.  It means that we should not concentrate on where we are in the project's overall life; instead, we should focus on what we need to finish that day.  It makes the emotional ups and downs less severe.  

Taking the work day-by-day allows you to filter out the politics around projects and the petty displays of status you see in corporate environments.  When problems linger, you gather together with others to find solutions.  It is hard to do because the people who begin enterprise-level projects are not around when they finish.  It is why you look at each day as a single unit and judge your success or failure on how you meet the goals of that particular day.  You build up good days and attempt to shrug off the bad ones to create a body of work that meets the project's long-term goals.  Brooks is correct projects do fall behind day-by-day, but they also succeed daily.  

If you are a coach or scrum master, instill this notion in your team.  The team is building big things, but they create many small items, adding up to something spectacular.  Improving one percent a sprint means an improvement of over twenty-six percent over a year.  Improving team performance like this often gets people promoted in corporate environments.  It makes working on the team more satisfying and lowers the stress levels of everyone on the project.  

Lewis Carroll said, "…between the idea and the reality lies the shadow." Taking work day-by-day allows you to handle better the darkness which occupies the shadows of your project.  It is not easy, but nothing worth doing is. 

Until next time. 

Smash Dependencies on Large Agile Projects

Working as a technology professional does not have the working-class credibility of being a plumber or ironworker.  We do not get dirty, and we do not pay a physical price for our work.  The worst injury we can suffer on the job is a repetitive stress injury or the occasional heart attack caused by chronic stress.  The biggest challenge in the profession is coordinating numerous savvy professionals to work together to accomplish a goal.  Today on the blog, I want to take time out to review dependencies for agile teams and mitigate them.  

When a project is small enough to require one agile team, dependencies are not a significant problem.  Often, the scrum master or a team member will take the initiative and address the situation.  At most organizations, a different team manages the production servers,  so when it is time to promote code into production, someone from the agile team makes arrangements with the server team.  Dependencies are simple on these projects. 

A larger project quickly becomes a tangle of dependencies.  For instance, an extensive enterprise application might have an AS/400 team working with enterprise data, a group writing a web interface, and finally, a group writing middleware to connect the two.  At this point, dependencies grow on a logarithmic basis.  Add an extra team, and the number of dependencies jumps from three to six.  Add a fifth team, and you get ten and so on until you get a tangle of communication channels.  The PMBOK guide has a fancy mathematical formula to calculate how these systems get out of control.  

Doing the math, a team of ten people or groups has forty-five different connections.  It is clear to see that the number of links and dependencies will be a problem for people to follow.  

The solution to this problem is to isolate those lines of dependency to make a clear connection between groups.  In my previous example, the middleware team is connected to the AS/400 team and the web interface team.  Upper management wants to add a team to write a mobile application.  Instead of linking the mobile development team to the middleware team and giving them more dependencies, the new team should collaborate with the web team because they already understand how to connect to the middleware already generated, saving cycle time and distractions. It seems counter-intuitive, but the knowledge from the web team will be more valuable than the middleware team attempting to educate the mobile application team on how to consume the web services.  Organizing your groups in this fashion prevent your dependencies from looking like the bedroom wall of a conspiracy theorist.  

To address dependencies, isolate them into narrow paths to reduce the number of connections between groups.  Not only does this conform with the PMBOK Guide, but it conforms to the theory of constraints because it allows a scrum master or coach to isolate and exploit limitations in a system.  Doing this will help remove complexity and lower your stress levels below heart attack severity.  

Until next time. 

Agile and Leadership Means Pissing People Off.

I am a fan of military history and wargaming.  The stories of veterans and the high stakes of combat have informed my worldview.  This blog even featured an article on how Dungeons & Dragons helped me become a better scrum master.  A fascinating thing about military history is the stories of personal heroism and leadership which occur when everything is on the line.  Stories of grace under pressure are an inspiration for me, considering I work in the intense world of technology.  Earlier this month, one of my heroes died from complications from COVID-19, Colin Powell.  His legacy is complicated in American history, but his insights on leadership are something people in the agile community should emulate.  

Powell did not have an impressive pedigree when he became an officer in 1958.  He spent the early years of his career learning his trade, and it was only in Vietnam that Powell’s career took off.  The young officer had a knack for solving problems and turning around dysfunctional units.  His superiors considered him competent, hard-working, and loyal.  Powell’s superiors fast-tracked his career.  

Where Powell distinguished himself, he was chairman of the Joint Chiefs of Staff under President George H.W. Bush.  Taking lessons he learned throughout his career, Powell innovated warfighting by toppling Manuel Noriega’s Panamanian government in 1990 and leading the Pentagon during the First Persian Gulf War.  I remember his collaboration with theater commander Norman Schwarzkopf and his declaration that the allies in the first gulf war would “…cut off and then kill.” Saddam Hussein’s forces in Kuwait.  

When he retired from the military, Powell wrote a best-selling memoir and spent his time public speaking.  Before being named Secretary of State by George W. Bush, he was a best-selling author and gave numerous workshops on leadership.  During the intermission in his public career, he continued to provide leadership speeches, and one of my favorites was in 1996, where he outlined some observations of a lifetime career.  The most important was, “Being responsible sometimes means pissing people off.”

To Powell, getting the job done is more important than being popular.  Building consensus and attempting to please everyone is a sure-fire way to mediocrity.  Often there are too many cooks in the metaphorical kitchen, and someone needs to make a decision.  When someone is in charge and makes a choice, it is going to get second-guessed.  Others will be unhappy with the decision because they will exert themselves more than they usually would.  Finally, a decision might expose someone as unable to do the work to the level of quality demanded.  Someone will always be pissed off with a person showing leadership.  

Agile makes this doubly accurate as the rapid cycle times and demand for working solutions are required.  People who get by on charm and a smile can no longer hide in plain sight.  Items missed are visible for everyone to see.  Technical debt which is missing during a demo shows up in testing or production environments.  All of these things are great at pissing people off.  

So as a leader and agilist, pissing people off is a natural consequence of the job.  It is asking why a deadline promised ninety days ago was missed.  A coach will ask powerful questions about server configurations and testing plans.  Leadership can be such a lonely job because if you are doing it properly, some portion of the people you serve will be pissed about a decision you make.  Once I internalized that message, I found leadership to be less lonely.  

I do not want to make Powell into some demi-god.  He has a complicated legacy which includes involvement in stonewalling the investigation of the My Lai massacre.  He also tarnished his reputation with his advocacy of the Second Persian Gulf war.  It is why biographer Jeffrey J. Mathews calls his biography of Powell “Colin Powell: Imperfect Patriot.”  We can learn from this imperfect man the principles of his leadership style, which served him well over his career.  The most important to me is that a leader pisses people off.  

Until next time.