What You discover at a coaching retreat

Why teammates from the Agile Coaching retreat.

I have been offline for a few weeks.  The reason was I had to have some downtime as I was involved with a conversion of a TFS 2015 server over to an instance of VSTS.  Also, I was getting ready for a trip to London for the Scrum Coaches Retreat.  The pressure along with the time requirements forced me to set aside my writing.  Things have settled down, and so I can get back to writing about agile.

It has been a whirlwind three weeks.  Family functions, work, and this trip to London have been my focus.  When you have time out for yourself, you learn a few things.  The primary lesson came from a scrum master I met from England.  Dominic Kavanaugh who pulled me aside during a stressful moment and said, “This retreat isn’t about shipping anything; it is about learning.”  From that moment, I had an epiphany.

The agile manifesto says working software over comprehensive documentation.  The principles of agile stress shipping software in small increments.  What I realized is I have forgotten a fundamental lesson about continuous improvement.  Learning and growth are a vital goal of being agile.  Shipping software is not a hamster wheel where everyone goes around and round shipping software and not improving.  It was my big revelation.

The revelation came as my team of coaches came upon the idea of “Healthy Ownership.”  I was complaining about the abusive relationship developing between my product owners and developers.  Soon another joined my group and spoke about quality assurance not working well with developers.  Finally, Dominic entered the group and talked about technical debt.  What united all three of these themes was that the development teams did not have a shared sense of ownership to the work they were doing.

Together, the team of us set out on a journey to try and come up with a way to discuss dysfunctions and how to fix them using a coaching approach.  It was the first time I exposed to terms like “clean language,” follow-on questioning, and guided conversation.  It was positive to have ten strong personalities in the room who were all success focused.  One person was our enforcer of norms.  The other was making sure we covered the topic of quality assurance.  Another was our enthusiastic product owner.  All of us learned to work together in three short days, and we came up with a “Healthy Ownership” model of coaching.

I am pretty proud of the small part I had to play in the creation of this tool; I hope to use it for the remainder of my career.  First, it is a descriptive approach to solving problems.  Often as a coach or scrum master, you want to jump in with an answer to a technical question or process problem.  It may answer the question, but it impedes self-organization on the team.  Next, we approach issues like a doctor looking at symptoms.  We gather information, ask a few questions and provide the right nudge to a person.  Finally, we are just getting started.  All of us have committed to being ready to improve and flesh “Healthy Ownership,” out.

I was not sure what I expected at the coaching retreat, but now that I have attended one, I see it as a valuable and worthwhile experience.   I am looking forward to going the next time.  I am also looking forward to sharing with you my experiences.

Until next time.

No Estimates have a spot at the Campfire

Lots of debate around the campfire.

One of the best things about being a member of the Agile community is the smart and enthusiastic people you encounter online and in person.  It is refreshing and challenging to be around people who have a shared vision of making business faster, sustainable, and more intelligent.  The commitment to the goals of agile does not mean we are ideologically unified and dogmatic.  Like any healthy practice, we disagree with each other about basic principles, ways to spread adoption, and innovations.  The creative tension is essential.  I want to add my two cents to an on-going debate which a colleague Ryan Ripley brought to my attention from the sober and restrained convention floor of the #BetterSoftwareCon in Las Vegas. 

The #NoEstimates movement has become a very vocal camp in the agile reformation.  If you follow the debate, it is easy to see why.  The estimation process at many companies is farcical and corrupt.  Story points were created to provide the benefits of estimation without the obvious drawbacks.  The #NoEstimates crowd take this to a logical conclusion and say estimating is a waste of time and energy.

I do not feel very strongly about #NoEstimates.  What makes it interesting is it provides a different perspective to authoring software.  Neil Killick then posted a white paper this week showing some qualitative measurements which show a no estimates approach works just as well as a story point approach.  

I was skeptical but, I decided to give the article the benefit of the doubt.  Killick uses T-Shirt sizes to measure ambiguity and difficulty.  Using arithmetic and charts, he shows how he can forecast project completion.  The approach is well thought out and clear.  It is also story points dressed up to look like #NoEstimates.  It requires the product owners to spend time doing arithmetic instead of writing stories and working with customers and developers.  Personally, I struggle getting product owners to perform the basics of their duties.  Thus, using Killick’s approach may work for a different agile implementation but not for mine. 

I genuinely dislike debates which generate more heat than light.  Killick provides a good approach for a more mature agile team.  I am glad I had a chance to learn about it and will keep it in my chest of tools if I feel it worth trying.  The agile manifesto says, “Individuals and interactions over, processes and tools.” I believe that Killick’s approach is a process which might work with a particular set of individuals.  I also think that discussion of #NoEstimates is good for the agile movement.  People try out ideas, test them, and they are adopted or rejected over time.  It sounds mighty agile to me.

Until next time. 

Break out of your rut!

I have been thinking about my craft.  A scrum master is a coach, therapist, and advocate for their team.  We have emotional ups and downs in the profession.  We are also fortunate enough to make a difference in the organizations we work.  It is rewarding but filled with the trade-offs professionals are confronted.  This week wanted to discuss a constant force in the life of a scrum master continuous improvement.

As a professional, it is easy to get into a rut.  Decision fatigue sets in and so you order the same thing for lunch or manage how you deliver software.  Routine and inertia are comfortable because it provides a false sense of security in an uncertain world.  Your heart could stop from a simple blob of cholesterol or the company share price could crumble overnight, but thanks to the routine we ignore these catastrophes.  Inertia is safe and secure.  It is also the enemy of continuous improvement and agility.  It is why scrum requires retrospectives.  The feedback allows everyone evaluate how to improve. Development includes the product owners and the scrum master.

I was doing a product increment planning meeting for the product owners to coordinate releases and plan for the future.  On a whim, I decided to include a retrospective of the last quarter to get a sense of where we are and where we are going.  A tense hour later a few lessons were learned.  Using a four “L” retrospective, I wanted to understand how as a product development team we were doing.  The answer was unambiguous.  Some things which we could control had to change.  The retrospective included passive aggressive conduct, and a few choice criticisms pointed at me.  It was worth it.

Based on what I learned, I am going to conduct retrospectives differently with the development teams.  I am going to work with the product owners more closely to help them manage their work more closely.   Finally, I am going to try and break out of my decision fatigue.  Continuous improvement matters, and if you expect it of others, then you should expect it of yourself.

Until next time.

Scrum does not have too many meetings

Each reform in society is confronted with a backlash.  The Protestant Reformation spawned the Inquisition.  It is natural that those threatened by it would oppose progress.  It is happening in businesses across the nation with the Agile reformation.  A common objection many have toward agile or scrum is there are too many meetings.  This week I want to discuss agile and meetings.

According to the scrum guide there are four events in scrum, they are:

• Sprint planning
• Daily Scrum or Stand-Up
• Sprint review 
• Sprint retrospective.

In the span of a work week, these meetings should be brief and informative.  A stand-up meeting should take approximately fifteen to thirty minutes.  If it takes longer, you should review how you are facilitating this meeting.  A sprint review is a demonstration to the business users and should take no longer than an hour.  Retrospectives allow a team to inspect and adapt their process.  Typically, this meeting is about sixty to ninety minutes in length.  Finally, there is sprint planning where the development team estimates stories and plans the next race.  Sprint planning can take as little as an hour and as much as six.

Based on this rough estimate we can determine how many hours the agile team is spending in meetings.  Based on a three-week sprint where is how it break down.

• Typical work week 40 x 3 = 120 hrs.
• Standup meeting – 0:15 x 15 = 3:45 hrs.
• Sprint Planning – 6 x 1 = 6 hrs.
• Sprint Review – 1 x 1 = 1 hrs.
• Retrospective – 1 x 1:30 = 1:30 hrs.
• Total Time budgeted in meetings = 12:15 hours of a 120 hrs. sprint.

Thus, a developer at worse case scenario spends just over ten percent of their time in meetings.  The remainder of the time is devoted to writing software and creating value for customers.  It is significantly less than in the world of waterfall project management with its numerous meetings to cover everything from architecture to problem-solving.

The scrum master and product owner spend their time in meetings, but it is to protect the team from being distracted from delivering value.  It is why I attend meetings about I.T. governance or architecture so that my team does not have to.  It is why the product owner is answering customer inquiries and meeting management.  We attend the meetings so the development team can concentrate on what is important which is shipping code.

It is why I find the argument that agile has too many meetings disingenuous.  People who are opposed to agile are not opposed to the meetings they are opposed to the routine nature of the meetings and the expectation to ship working code at the end of each sprint.  Transparency of this nature quickly exposes the unwilling, incompetent, or invisible people in an organization who do not deliver value.  When we discover these individuals, it creates a backlash in the organization.

So, scrum and agile does not spend too much time in meetings; it concentrated on what is essential.  An agile team’s first and foremost duty is to deliver value to the business; anything else is waste.  I am looking forward to hearing from you and knowing what you have to say.

Until next time.

Story Points for the Misinformed

It is all about planning poker.

Last week, I wrote a harsh critique of how project estimation is done at many organizations.  I do not like using the words farce and tragedy lightly, but in my experience, many projects devolve into these realms.  This week, I want to talk about story points and how they solve some of the problems I discussed how estimation is broken.

I have written two essential blog posts on story points.  The first was my reappraisal of story points as measurements of difficulty and ambiguity.  The other blog post illustrated how story points could be used to meet deadlines.  Reviewing those blogs, I think they are a clear explanation of the advanced uses of story points.  For those new, to story points, this blog is for you.

Last week I said traditional forms of project management rest on the mistaken notion that time and money equal the same thing.  It means when a project manager or developer gives an estimate and executive treats it like a quotation of work.  The experience is similar to going to an automotive mechanic receiving an estimate for $300 of work and getting a bill for $3,000.  As a consumer, you were expecting and budgeting for a $300 bill.  When confronted with an invoice ten times larger than expected, a person usually falls into a spiral of rage.

Story points defeat this situation.  First, the team members are playing planning poker and are collectively deciding how many points it takes to complete a unit of work.  It is not the opinion of one person be a consensus of numerous technical professionals.  Next, story points are the sum of ambiguity and difficulty of a unit of work.  There is no meaningful way to convert a story point into money or measure of time.  The only things that are certain is a team can complete a specific number of story points in a sprint time box.  The average number of story points completed over at least three sprints is called velocity.  I illustrated in an earlier blog velocity allows executives, scrum masters, and developers a means to forecast deadlines.  Finally, story points allow for severe discussions about scope, resources, and time without having to discuss dollars and cents.

My colleague, Steve Sether, points out story points are not a silver bullet for poorly managed projects.  Story points can be inflated to create the illusion of increasing velocity. Accountants attempt to put a dollar figure to story points and executives often ignore them to make promises without consulting the development teams.

For me, telling an executive, we have 213 story points in a software backlog is much more informative than claiming we can hit an arbitrary deadline.  We can take some action and make more informed decisions rather than rely on gut instincts.  Project estimation should not be farce or tragedy; with story points, a development team and a scrum master have a better way of estimating work and delivering to the business.

Until next time.

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.

Choose a Growth Mindset

Growth is not easy in this business.

One of the major features of agile is its emphasis on continuous improvement.  Teams, people, and processes can always get better.  If you do a 1% improvement each sprint and perform three-week sprints over the course of a year that equals a 17% improvement by the team.  Many times, small improvements are equivalent to significant increases over the long term.  What works with software development teams also works for scrum masters.  A scrum master should consider continuous growth to be a personal goal in their practice of agile.

I am currently working on becoming a Certified Team Coach.  It has been a time-consuming process with me logging hours and filling out forms.  I reviewed the five dysfunctions of a team and practiced SOLID code development.  I was about to file the first part of my two-part application when someone suggested that I get a pre-screen.  I was deeply disappointed by what happened next.  My screener said the first part of my application would be accepted, but I would ultimately be rejected in the second round because I did not have a “coaching mindset.”  I was disappointed.  It was as if the last five years of blogging, coding and being a scrum master were an empty exercise.  I was given a verbal pat on the head and sent on my way.

After doing some reflection, I went over my notes, and there were some suggestions for graduate-level courses in coaching.  I also spotted a class from the Harvard Business Review on coaching for leaders.  The pre-screener was even kind enough to recommend some graduate-level course in coaching which was local.

Maybe I was not ready.  During this time of reflection, I was exposed to the work of Stanford University professor Carol Dweck.  Her most influential idea is people to be successful need to move from a fixed mindset to a growth mindset.  This very positive idea is one which postulated that everyone is capable of growth and improvement.  Having a growth mindset means that development only happens if people actively seek improvement.  Traditional command and control methods of leadership are less effective than asking questions and having people find solutions rather than having them provided for them.  As I said, it is optimistic.  Professor Dweck can fail students who do not turn in the homework.  Me, I am stuck with product owners who will not write user stories.

I can see a few scrum masters and executives shaking their heads.  Authoring user stories is a fundamental part of being a product owner.  A leader with a fixed-mindset would take disciplinary action or try to teach that product owner to write stories promptly.  A growth mindset leader would ask questions, guide mindset, and follow up with the product owner to get them to improve on their own.  It is touchy-feely and genuinely optimistic.  It also runs counter to how I learned in the field of media and technology.

I was skeptical, but I decided to give it a try.  What happened next was a surprise.  A person responded positively.  They got better at what they did.  They did not improve as quickly as I would have liked, but they did enhance so after four weeks I noticed a difference.  Furthermore, when the person did things which usually triggered in the past, I saw a different motivation.  Now, instead of seeing them attempting to undermine my credibility or authority; I saw them checking for understanding and holding others accountable.  The situation is not entirely sunshine and rainbows, but it is improving.  I should embrace improvement over stagnation.

So here I am attempting to adopt a growth-mindset and continuously improve one small step at a time. Taking a growth-mindset is the next step in my agile journey.

Until next time.