Tuesday, August 14, 2018

Looking back at Agile2018

Spending time with fellow
 speakers Michele Sliger and Erika Lenz
This year is a personal and professional adventure for me.  I journeyed to the Scrum Alliance coaches retreat in London.  Last week, I was a presenter at the Agile 2018 conference.  Each of these experiences has made me a better scrum master and agile coach.  Now, that I am back home and have a more stable schedule; I will be blogging on a more regular basis.  This week a few take-a-ways from the #Agile2018 conference.

Data and Metrics-

The Wednesday keynote was Troy Magennis who spoke passionately about data and agile.  He proposed that agile professionals find a better way to present data to others and that data should inform decision making rather than reinforcing existing prejudices. 

He also provided data showing notions of teams being smaller than nine people may be counterproductive in larger projects.   He pointed to studies where groups of eleven to nineteen people are less efficient by a fraction compared to seven to nine-person teams.  He then argued that fewer handoffs between teams would make up for this difference.  It was provocative, and I look forward to people testing out his thesis. 

Presenting for the first time. 
The conference featured numerous presentations on metrics and data in agile.  I believe the use of quantitive data rigor in project and business management is a good thing.  For the remainder of the conference, numerous sessions covered the use of data and metrics in Agile. 

Outcomes are better than output-

The Agile Alliance with its speakers unwittingly created a theme for this conference.  The idea was outcomes of real features and progress are more important than outputs of stories, unit tests or story points.  Countless presentations emphasized working code delivering real-world value.  My presentation about the Cobra Effect reflected this dynamic as well.  When we measure outputs, we get perverse incentives.  When we measure outcomes, we get a better perspective of performance. 

Facilitation and Radical Candor-

The life of an agile coach or scrum master is a life of responsibility without any authority.  It is paramount to successful organizational change coaches develop superhuman skills of persuasion and facilitation.  I attended several sessions on how to be more credible and persuasive.  Many of these sessions pull from the insights of Kim Scott, a former Google Executive, who authored the book, “Radical Candor."

I learned plenty of valuable lessons at #Agile2018, and I look forward to the next conference in 2019 in Washington D.C.  I better start working on my presentation outline. 

Until next time.


Monday, July 30, 2018

How I became a Pirate Bear

I am a pirate bear. 
If you have been following this blog for any length of time, you understand that I have been an outspoken advocate of Agile and Scrum.  It has become the central focus of my career.  I am one of those eccentric and creative people companies want but do not know how to utilize.  I am an anomaly in the business world, and I am comfortable with it.

Like any other technology professional, I spend my free time learning new skills.  In preparation for the Scrum Coaches Retreat in London, I spent some time learning how to use #slack.  To be honest, I am still struggling with the platform.  It feels alien to me.  I have not mastered all the tricks, lingo or etiquette of a #slack community.  I think the same way I did eight years ago when I started using Twitter.  I was able to master that, and I will be okay with the new platform.

When you join a new social network one of the more important things you do is choose a name where others can quickly identify you and touch base.  The same is true with #slack and since the network does not allow for duplicate names people rapidly get creative coming up with handles.  I decided to give myself the moniker “The Pirate Bear.”  I posted a color picture of myself in a fez and began my journey in #slack.  I was swapping information, slide decks, and gossip with other agile coaches for a few weeks when someone from England asked why I chose “The Pirate Bear.” I did not have a chance to answer the question then but feel compelled to answer it now.

Since I began my vocation as a technology professional, I have been heavy.  I blame this state of being on the nature of the profession and by using food to cope with the pressures most technology professionals confront.  I am both big and tall.  It prompted the woman who loves me to label me her bear affectionally.  Additionally, many of my LGBTQ friends and colleagues say that I would pass as a “Bear” in the gay community. I felt awkward about this at first, but I embraced it as good-natured teasing from friends.

Piracy has been a significant theme in the zeitgeist since Johnny Depp wore the costume in the first Pirates of the Caribbean movie.  Piracy has been the banner many rebels and outcasts have embraced since the age of sail.  Illegal radio stations sailed the North Sea offering programming the BBC would not provide. It became a pirate radio which has been copied by numerous radio stations around the world.  When Steve Jobs put together the product team of the first Macintosh, he told each of the engineers, “It is better to be a pirate than to join the navy.”  The secret pirate crew then changed personal computing forever.

It sounds very glamorous. The swashbuckling and mythology of piracy is quite appealing.  The reality is that a pirate’s life was dangerous and cruel with significant shifts between poverty and wealth.  A pirate sailor often faced execution if captured and often succumbed to illness at sea.  You chose piracy for many reasons, but the main reason is that you did not fit in anywhere else.

In the sclerosis of most corporate environments, if you are going to make a change, you will have to be a pirate.  You will have to be smarter, nimbler, and more unconventional.  You will suffer from being an outcast.  You may also fail in an embarrassing and ignoble fashion.  On the off chance none of that happens, you will cut a romantic figure in front of black sails and wallow in gold and rum.

Given a choice between the routine and tedium of a professional career and being a pirate; I choose to be a pirate.  It is why I am the pirate bear on #slack.

“Roar!”

Monday, July 23, 2018

Coaching should reject triage

Good for the battlefield bad for society and business
Usually, I spend my time on the blog discussing agile and how to better improve software development.  I avoid political discussion because there are much better places for people to discuss that topic.  This week, I would like to discuss something different.

This week a young person I have known since her days as a college undergraduate wrote and thoughtful post about her struggles with mathematics in elementary school.  As early as fourth grade she was taken on field trips to grocery stores to learn about careers stocking shelves after completing school.  None of the other students attended that trip.  As early as nine years of age educators and members of the community were making decisions about her life.  Today, Stephanie Orme is a Ph.D. from Penn State who is a nationally recognized public speaker and recently gave a TED talk on Diversity Game Design.  

I am very proud of Stephanie.  I consider myself one of the stepping stones on her journey and I look forward to seeing her further adventures in academia.  Her story made me think about my trip educationally and as a scrum master.  We make too many judgment calls about young people, and those judgments are harming our society and the business community.

Our education system in the United States has wide gaps of inequality.  Private schools appeal to people of means and have been training grounds of the children of business and political elites for the last 100 years.  Parents often pay a premium real-estate prices to live in communities with highly rated schools.  Young people living in rural or poor school districts are not so fortunate; it means that school districts make do with what they have, and they get involved in a practice known as triage.

Initially, from the medical field and pioneered by the French during the Napoleonic wars triage means the sorting of people to help them when confronted with scarce resources.  For example, someone with a head missing from a cannonball does not need a blood transfusion that blood can go to someone with a better chance of survival.  Paramedics, emergency rooms, and combat medics use the concept of triage daily to save lives.

As early as middle school, I experienced triage in my education.  The “smart” students participated in honors courses and segregated from other students.  These students not only had to have good test scores but they also had to have good grades.  The poor students were in remedial classes, and the unwashed middle got by with standard courses.  The exception to this rule were those with cognitive and learning disabilities who received special education.  I was terrible at mathematics, so I attended learning disability courses.

As time wore on, the honors students became more privileged as standard and remedial students shifted into less challenging classes.  Honors students received college AP courses, scholarships, and opportunities to excel. Once labeled a basic or a standard student, opportunities to reach the upper echelon was difficult.  It created a type of resentment and desire to prove those who doubted me wrong.

I was more fortunate than most.  My community college prepared me for university study. I was lucky enough to receive a scholarship to a four-year school for debate and speech.  Thanks to the financial sacrifices of my parents, the incredible support of my teachers, the encouragement of countless adults, and a little luck I became a college graduate.  If you had checked in with me as a nine-year-old, you would have concluded that I would be stocking shelves.

It would take seven years working in the radio and the casino business to find my true vocation; software development.  It would take another ten years before I would discover agile and share its worth with others.  I got by on grit, but I would be fooling myself if I did not acknowledge the privilege of supportive parents and my educational background.

It is this knowledge which has shaped my perspective.  The Harvard business review talks about a “fixed mindset” vs. a “growth mindset.”  Thanks to triage in education, we take young people and place them into boxes.  We then triage those boxes into careers and roles in our community.  It is a more significant problem in business because often leaders are more comfortable around people with similar educational and cultural experience.

As someone who has not fit neatly into a box his entire life, it encourages me to adopt a growth mindset for others around me.  I cannot help everyone, but I will try to help those I can.  With a little luck, there will be more people like myself and Stephanie Orme helping reform business and culture.

Until next time.

Monday, July 16, 2018

Why Healthy Ownership

"Healthy Ownership" created to fight abuse
I have been in deep thought about what we in the agile community need to do to make businesses more responsive to market demands.  The reality is that many relationships in the technology world can be abusive; this why I want to talk about the reasons why I have been working on “Healthy Ownership.”

It is not a secret that software developers can be jerks.  It is also not a secret that there are plenty of raging asshats in the technology business.  Finally, if you work in a shrinking industry, the pressure to do more with less can be absurd.  With all of these realities, there is no reason to be involved in the following behaviors.

Questioning the estimates of a development team.  

I have written several times about the underlying social contract of agile.  Product Owners set priorities and development teams to estimate how long it is going to fulfill those priorities.  I had a product owner question those priorities saying, “You did something similar last sprint so I thought you could do it faster this sprint.”  All user stories should be negotiable but for things like scope and acceptance criteria.  When product owners start questioning how long it takes to complete that scope you break the social contract of agile.  It is this kind of conduct which demotivates the development team and gives them license to question the judgment of priorities of the product owner. 

Not writing a unit test or chipping in with QA work.

I have known developers who have looked down on quality assurance people.  Experience tells me that these individuals are not very good developers.  Software development is complicated, and the process of authoring it creates intellectual blinders.  Quality assurance people guarantee that those blinders are less convincing.  They ask uncomfortable questions, probe weaknesses in logic and are willing to take a sledgehammer to a sink to make sure that everything works as promised.

Quality assurance people help developers improve, and developers help QA people understand what they are testing.  A recent blog post mentions a professional golfer is not finished with a hole until they put the ball into the cup.  For weekend beer league golfers, it is good enough to get it close to the hole and “pick it up.”  Writing unit tests and doing QA work separates professionals from beer league developers.  Refusing to do this means you are rejecting the professionalism of your craft. 

Ignoring refactoring and technical debt

Technology is a brutal business.  It is unforgiving and humbles the best of us.  It changes so quickly; a developer needs to relearn their job every eighteen months.  It means that code they are working on needs continuous refactoring.  What is working in the short term may be hard to maintain or adapt to changing business needs.  It is why technical debt and refactoring matter.

Many people in leadership roles have a, “if it is not broken do not fix it,” attitude.  Neglecting technology is like ignoring your household plumbing.  It may work now but when it does break it is going to create a tremendous mess.  Paying attention to technical debt and refactoring is common sense like changing the batteries on your smoke detectors. 

All three of these pathologies brought me and others together to create “healthy ownership.”   These behaviors are abusive and counter-productive to any team.  Only be addressing these dysfunctions will the practice of software development improve.

Until next time.

Monday, July 9, 2018

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.

Monday, June 11, 2018

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. 

Monday, June 4, 2018

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.


Tuesday, May 22, 2018

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.

Monday, May 14, 2018

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.

Monday, May 7, 2018

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.

Monday, April 30, 2018

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.


Monday, April 23, 2018

Machiavelli knows agile.

Machiavelli, knows some things about agile.
The agile reformation is all about satisfying customer needs, improving product quality, moving quickly and maintaining a sustainable pace of work.  These differing prerogatives require changing the way we think about work and looking at problems differently.  It means for agile to be successful a scrum master or coach must lead change.

Many times, I feel like Don Quixote jousting at windmills around the office. During a down period, one of my product owners pointed out a quotation from Machiavelli.
“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things.” 
Leave it to the prince of political manipulation to provide me with some fodder for my blog.
Change is hard because people prefer to have routine and ritual in their lives.  Also, people who benefit from the way things are will resist change because they might lose authority, money or status.  It is easy for individuals to see reform as a zero-sum game with a gain for someone else equal to a personal loss.  It is a pathology which I see in both technical and business professionals.

On the business side, it is a huge culture shock to work side by side with technical professionals.  Now they discover the systems and technology they take for granted is not the result of magic.  They collaborate on the authoring of requirements, and they have “skin in the game,” when it comes to the success or failure of an initiative.  No longer will the alibi of, “…it is technology’s fault,” work in an organization behaving in an agile fashion.

The rapid feedback is a benefit to both the business people and technology staff.  It avoids “death march” projects.  The days of building software which does not drive value to the business disappear with each iteration.  A software project can quickly pivot to new regulatory or market needs.  Finally, the CFO will see a reduction in cost overruns and failing projects.

Agile not only changes the business professionals who practice it; agile changes technology professional who follow it.  Developers begin to understand the challenges the business faces.  An engineer sees business partners as equals and worthy of respect. Writing unit test and performing automated deployments build trust with business partners as bugs and defects decrease.  The arrogance of software professionals being the smartest people in the room gives way to the humility of helping others succeed.  The hacker ethos of development gives way to a more professional perspective.

Agile is not perfect.  The reformation is only eighteen years old, but it is growing and improving.  It is starting to become the de-facto technique of doing new software development, and it is spreading to other areas of business.  Change is perilous.  Getting knocked off your horse is not fun, but nothing worth doing is easy.  The reformation is not going to stop and you either lead, follow or get out of its way.

Until next time.

Monday, April 9, 2018

This reformation may take a while

Progress takes time.
  Image courtesy of Pawel Jonca.
The history of progress and social change is rocky.  The first feminists from the Seneca Falls convention did not live to see the passage of the women’s suffrage.  Women would continue to struggle for equal rights and acceptance outside the home and today women in technology face the soft misanthropy of “Brogramer” culture.  It is discouraging that each step forward leads to another pushback from people who feel threatened by that change.  It has been on my mind as I see businesses struggle with accepting the agile reformation sweeping business. 

Like many technology professionals, I receive e-mail messages daily from recruiters.   These individuals want me to sell my home and relocate to remote parts of the country for six to twelve-month contracts.  I ignore these messages politely or reply that I am not interested in relocation.  This week I receive a notice for a “scrum-project manager.”  I was intrigued.  I glanced at the requirements, and this is what I found. 


  • Two to three years’ experience in SCRUM
  • Two to three years’ experience as a BA/Project manager.
  • One or more years of Experience in JIRA.
  • Great Communicator.
  • Organized.
  • Salary 50k to 75K


I did a double take and then attempted to unpack this request.  According to the Scrum guide, there are only three roles; developers, a product owner, and scrum master.  There is no mention of a project manager.  Agile and Scrum according to the manifesto put, “Individuals and interactions over process and tools.”  I appreciate the author of the job post understands that communication skills and organization are not optional for a scrum master.  Finally, the salary requirements are laughable and way below the $100,000 national median compensation stated in LinkedIn.  For a company attempting to adopt agile, this is not a credible offer.

The person who wrote this job requirement should be embarrassed.  The salary is in the lowest percentile quarter of prevailing wages.  The author does not understand the role of a scrum master, and they confuse agile experience with project management.  Anyone who is thinking about this role should reconsider.  It will stunt your career growth, and the company appears to be paying lip service to Agile.

It is my hope businesses will do a better job writing these requirements and recruiting proper agile talent.  Unfortunately, this means executives and human resources professionals still have a long way to go before they understand agile and what it takes to be a twenty-first-century company.  Just like the feminists of Seneca Falls, after seeing job requirements like this, I am afraid that I may not live to see that change.

Until next time.

Monday, April 2, 2018

A sweet and sour career

The stuff of life.
It is the Christian holiday of Easter.  I am spending time with my family and friends.  I am also taking a look back at the start of the year.  It seems like only yesterday, I was counting down to midnight and wearing silly hats.  Now, I am wrapping up the first quarter.  I am unsure where the time goes.  This week, I would like to do a little reflection on the ebb and flow of being a scrum master.

I have repeatedly said on this blog being a scrum master is a calling.  It takes devotion and a touch of insanity to lead software developers and organizational change. I spend my days helping people ship software and then my evenings learning how to be better at my profession.  Someone I respect very much calls it the “sweet and sour” of a career.  Experiencing hardship makes accomplishment more meaningful.

This week I discovered I would be presenting at the Agile 2018 conference in San Diego.  I will be talking about the Cobra effect and how you can fight it.  It is a pretty significant accomplishment, and I am deeply grateful for the opportunity.  It also encourages me that I am not some voice in the wilderness.  I have spent nine years as an agilest, and it is profoundly satisfying that people are interested in the insights I have picked up along the way.  It is a lovely feeling.

The sour is the daily grind of putting out software.  I take calls from India each day.  I work with product owners to help them be successful.  I have created close bonds with my development partners because the pressures of shipping software are enormous.  It is early mornings and late nights.  It is cold coffee and petty arguments.  It is what must be done to create value for the business.

I accept the sour to appreciate the sweet.  Family, friends, and loved ones talk me through the sour times and help me celebrate the sweet.  It is not glamorous or pretty, but I have found meaning in the Agile reformation.  My life is a mixture of sweet and sour.

Until next time.

Monday, March 26, 2018

A lack of skin in the game for employees

From the blog: ON ART AND AESTHETICS
Last week I talked about three types of cultural factors which can make an agile implementation challenging.  I also spent some time catching up with some of my contemporaries discussing the application of Agile at different firms.  It was a disappointing discussion.  This week I want to talk about agile and the lack of follow through in many organizations.

I started thinking about the inability for the organization to improve their agile maturity when fellow agilest David Koontz posted an article from the Harvard Business review about the failure of digital transformation at many firms. It opened my eyes.  I then noticed a new book published by the author Nassim Nicholas Taleb called “Skin in the Game,” about the uneven relationships we create in the labor market.  The most telling passage was the following.

“True, a contractor has a downside, a financial penalty that can be built into the contract, in addition to reputational costs. But consider that an employee will always have more risk. And conditional on someone being an employee, such a person will be risk-averse. By being employees they signal a certain type of domestication.”

In short, being an employee of a large company creates people afraid of risk and rocking the boat. The company through its leadership and culture incentivizes particular behavior.  The employee trades their skills and dependability in exchange for a paycheck.  It creates situations where conscientious people tolerate ignorance and inefficiency because they say, “…that is how we have always done it.” Thanks to this submissiveness large firms stagnate and die.

It also explains to me why agile coaches are contractors.  In the words of Ken Schwaber, agile holds a mirror up to an organization.  Many organizations are not equipped professionally or psychologically to look at that reflection because they would see the incentives they have created are perverse and the services they offer are not meeting customer needs.  It is like being in the Jean-Paul Sartre novel “Nausea.”  The world we know crumbles away, and we see the disorienting reality of how things are working. Confronted with this we have three choices:
  1. Wallow in despair and impotence
  2. Ignore the truth and pretend nothing has happened
  3. Take action and try to make change

The modern corporation incentivizes employees to make the first two choices.  Those who choose the third option either quit or the company fires them.

So as a scrum master or agile coach we are stuck making a change at the margins and moving on when we cannot do anymore.  The global economy continues to spin, and nothing seems to change. It is easy to get discouraged, but the size and diversity of the agile reformation continue to grow.  According to Scrum.org, over 100,000 people are trained at Scrum.  Figures from the Agile Alliance and Scrum Alliance are harder to come by, but eighteen years ago the manifesto began with fifteen people in a ski lodge.   The growth of the movement has been increasing and today’s consultants and practitioners will become tomorrow’s managers, directors, and executives.  It is a matter of time, and the Agile reformation will be driving reform inside the business establishment.

So perverse incentives prevent businesses from being more innovative and agile. The good news is the agile reformation is growing and with this growth will come increasing acceptance.  It will not be easy, but it will be worth it.

Until next time.


Monday, March 19, 2018

Three types of failure in an organization.

When it all goes wrong
I have been spending plenty of time looking at best practices and patterns in software development.  The more I learn, the more I discover knowledge in the field is growing logarithmically.   Thanks to the web, developers and scrum masters can share hard-won wisdom.  Sharing this knowledge makes everyone better at what they do.  We can also gain understanding taking a look at bad practices and seeing how they hurt an organization. 

A maxim in the agile reformation is everyone should be allowed to fail early and often.  Failure is an early building block for future success and innovation.  I see failure as an excellent teaching instrument.  It means an agile practitioner should take a fair and empathetic view of failure and see what we can discover.  Agile practitioners need to call out what works and what does not.  Reviewing bad practices and business failure educates in ways success cannot.

The Cargo Cult

A cargo cult comes into being when individuals create totems and rituals to mimic success without understanding how to achieve that success.  I have blogged about this topic, and it came from South Pacific tribe who built faux airports and vending machines in the hope cargo planes, and Coca-Cola would return.  I see it with businesses who begin a digital transformation but do not want to change their command and control structure.  The open office movement is another excellent example where business leaders hope to improve collaboration and instead ruin employee morale.  The lesson is to discover the “why” and “how” something works before implementing anything in your organization.

Cultural Inertia

If you work at an organization where people introduce themselves by how many years they work for the organization instead of what they do for the firm you are dealing with cultural inertia.  The term inertia comes from the field of physics. An object can remain still or in motion as long as outside forces do not act on that object.  Complex business organizations exhibit this trait.  These organizations get accustomed to doing things a particular way.  These organizations hire and promote specific people.  Thus, when confronted with change they treat is like heresy or deviance.  Managers or executives kill ground-up initiatives.  Digital transformations fail because line employees have no buy-in.  As a coach or scrum master, inertia is going to be your biggest obstacle.

Software Samurai

Software development is a human activity which resists automation.  So far, no Artificial Intelligence can write C# code or take vague business requirements and turn them into working software.  Human beings are messy, complicated creatures.  Smart and talented people are messier than standard employees. Making matters worse is the glorification of the “Hacker,” or “Brogrammer” culture of software development.  It is a worldview which is misanthropic and sexist.  The glorification of a software developer as a disruptor, visionary, alpha-male, shaman and deity has a few consequences.  It creates a toxic stew of smart people who are smug and contemptuous of business partners.  It also makes developers behave like lonely samurai willing to show off their skills only to other developers in battles for supremacy.  By following “the way of the samurai,” these developers ship poor quality code which does not meet business needs and impossible to maintain.  When called out for this conduct a samurai will say, “If they were good enough a developer they could maintain that code.”  Samurai coders are why agile fails at the team level, and it is up to a coach and scrum master to help these individuals reform their ways.

So here are three ways agile can fail in an organization; cargo cults, cultural inertia, and software samurai.  Each of these situations spells doom for your agile maturity.  Be on the lookout for these examples of failure. 

Until next time.

Monday, March 12, 2018

XML Substitutions in Visual Studio Team Services.

One of the biggest challenges as a software professional is staying on top of the latest development practices.  I have been fortunate to be part of the Chicago Application Lifecycle Management group and know people like Donovan Brown who have shown me the power of continuous integration, dynamic releases, and using Visual Studio Team Services to reduce deployment time to a matter of minutes.

Today, I want to share with you a technical blog on how the management of configuration files is a breeze in Visual Studio Team Services (VSTS).

The first thing a rookie developer learns when they start working is NEVER HARD CODE ANYTHING in an application.  It is a significant anti-pattern, and it will make your professional life miserable.  To avoid this anti-pattern, .NET developers use App.Config and Web.Config files to save file paths, database connection strings, and variables which change sporadically.  When a Vice President or network administrator needs a change, the development team can correct the file without having to recompile the code.  Afterward, everyone involved can get back to business.  It was a great approach if you have one environment and one file to change, but many firms have multiple settings for development, testing, and production.

A developer has three options:
  1. Keep three separate files and maintain each of the files separately which is prone to error.
  2. User XML transformations in Visual Studio which is less prone to error.
  3. User XML replacements in VSTS or Team Foundation Server.

The first option is a recipe for disaster because you have to maintain three files and have an obsessive attention to detail.  I have lost numerous hours of sleep making file comparisons to find a configuration error.  The second option works, and I include a link how to do this from Microsoft.  The drawback is a developer must build the application three times; once for each environment.  It could create a situation where code may have the correct configuration file, but the compiled code may not match it.  The final option is the best because we perform one build and the configuration files change based on where the code is deployed.  The rest of this article will focus on how to use this approach successfully.

This example is a simple MVC 5 application which I am deploying to a staging/UAT environment.  Treat this as a “Hello World!” example of how you can do this in your organization.










In the web.config file create a variable which will change depending on the deployment environment.




Next, write a scrap of code to display that information in your MVC application.  Note: this code will break a unit test do not use this approach in professional code: see this link for more information. 



This next step is where the magic happens.  My network administrator installed the agent on servers and created development groups.  Navigate to the library tab and create a variable group by selecting the button labeled “+ Variable Group.”  Once you have done this, give the variable group a meaningful name.  In this example, I use “Development_Variables.” After providing a detailed description of the group, select the “+Add” link.  When you select the button, an inline form will appear; provide a name and then a value.  It is a key value pair which makes it possible to match the values in the Web.Config file.  Make sure the name of the variable matches exactly the spelling and case sensitivity in the Web.Config file, otherwise the transformation will not work.  Repeat this process and name the other variable group “UAT_Testing_Variables.”

Now that we have variable groups for each environment add them to a release pipeline; select the release tab in VSTS and select the “+” sign; “choose “Create Release Definition.”



You should see a screen similar to the one above.  For this example, I used a simple IIS Website deployment.  I add the build to the artifacts section then I create a deployment process.



The important part is in the IIS web deploy task.  Make sure the checkbox XML variable substitution is selected.  Select the variable tab in the pipeline chose the link “variable group,” button then pick a variable group you created in the earlier process.  Make sure the scope is “Environments,” and then set to “Development.”



The variable tab should look like above and when all these settings are made you are ready to test; kick off a build in VSTS.  When the build is finished, the code will be deployed to the development environment.  Upon a successful deployment navigate to the website on the development server.  The variable on the front page should be the same as variable defined in the variable group.

Using this process, you can maintain variables in VSTS without having to worry about configuration files and the variable groups can be secured via active directory.  Finally, configuration changes can be deployed without having to recompile code.  Thanks to VSTS and XML substitutions you have a smooth and error-free way to speed up the development process.

Until next time.



Monday, March 5, 2018

Watching the changes roll by

Heraclitus would be pleased
The Greek philosopher Heraclitus has a special place in my heart.  He was one of the first thinkers to observe the importance of change, and he coined a slogan which business people use each day.  Heraclitus said, “The only constant in nature is change.” This maxim in philosophy and business got a bit of a work out this week as the Scrum Alliance and Scrum.org announced two new training programs.  This week, I would like to talk about these new programs.

Scrum.org announced a new class and certification called Professional Scrum with Kanban.  My initial reaction was skepticism.  Kanban is widely discussed among agile practitioners and understanding how to do it properly is part of learning Scaled Agile Framework for Enterprise (SAFe).  I was confused.  With this wealth of information, why would anyone want or need a class on Kanban and scrum?  It occurred to me people learn in different ways.  Some individuals can handle self-directed learning on Kanban.  Other people, will benefit from classroom training and the guidance of an experienced trainer.  So, a course on Scrum and Kanban is not so strange or confusing. 

The next big news in the agile world is the scrum alliance announcing the Advanced Certified Scrum Master and the Advanced Certified Product Owner credential.  I was much less skeptical about this news.   I worked as an agile developer for four years before becoming a certified scrum master.  The credential gave me instant credibility with hiring professionals and with executive leadership.  What the training did not provide me were some of the soft skills I would need to be a more successful scrum master.  Abilities like active listening and creating a dialog with stakeholders were skills I would discover by trial and error.  The advanced program from the scrum alliance provides a solid background in the basics and the skills required to spread the use of agile to other parts of the business outside of technology.   As someone who has been a CSP for the last four years, I wish I had this training during the early portion of my career.  Now the scrum alliance is offering it, and it is a positive development for those who know the basics but wish to be more successful.

Any training and development from the agile community is a good thing for the people out in the field.  The sharing of knowledge and information between the different licensing bodies also creates a cross-pollination of ideas.  It prevents the practice of technology and project management from getting stagnant.  I use approaches from SAFe and scaling scrum with scrum side by side. I have to deal with waterfall budget processes and graft them to scrum teams.  Finally, I deal with business partners who think everything I do is magic.  I need all the training I can get to be successful and deal with those challenges.

Heraclitus was a teacher.  This founding father of change spent his time educating others about it.  If agile is to continue to grow and spread; its practitioners need more opportunities to improve their skills and gain knowledge.  It means these new courses are good news about the health of the Agile reformation.

Until next time.

Sunday, February 25, 2018

Incomplete leadership is good leadership.

The world has plenty of leadership styles there are leaders who inspire fear and others who foster deep admiration.  The spectrum streams from the sublime to the ridiculous.  My thoughts on the subject have evolved over the years.  I have experienced many forms of leadership and what strikes me most is this notion of the “mask of command.”  According to this theory of leadership, a leader must create a persona of command which conceals weakness from people who they work. This week on the blog I would like to do a little unmasking.

I was an early proponent of the “mask of command.”  I would have an air of authority and credibility.  Anyone who has worked with engineers, creative professionals, and medical workers will quickly realize this is folly.  All of these groups are exceedingly smart, and all of them have been trained to be skeptical.  They know when you are putting on a mask and when you are inauthentic.  Once this lack of authenticity is detected, these kinds of professionals will tune out. 

Since professionals are not receptive to the mask of command, there has been a myth created around leadership.  Leaders of organizations must be “complete.”  They must have experience in the industry, work their way up the organization, and have the perfect mix of personal traits to succeed.  It has fostered a leadership style which discourages innovative thinking.  Bland and uninspiring leaders advance because they reflect the status quo of their organization.   They are not leaders but rather caretakers of their organizations.  The corner office and perks of executive leadership are enough to keep these individuals content.  If they are lucky, they will retire and let someone else do the necessary organizational change.  It is how organizations wither and die.

If the mask of command creates inauthentic leaders and the desire for perfect leaders creates uninspiring leaders what should a scrum master or agile coach aspire?  I have been thinking about this for some time.  It did not become clear to me until I read Deborah Ancona's essay in the Harvard Business Review, “In Praise of the Incomplete Leader.”  In her essay, Ancona talks about the myth of a perfect or complete leader who in her words is a “…flawless person at the top who’s got it all figured out.”  Today, organizations with their inherent complexity and global reach require “incomplete,” leadership who can delegate their weaknesses and play up their strengths.  Leaders do not have to be the perfect fit instead they should be good enough to help the organization.  Instead of the emperor or general, a leader is more like a therapist or pastor to support the organization see a better way. 

Ancoma goes on to describe four leadership skills every person has in varying degrees: sensemaking, relating, visioning, and inventing.  Those traits overlap each other, but it is clear to me that if you are equally good at all four of these areas, you are not good at any individual area.  Steve Jobs was fantastic at visioning; he was lousy with people and relating.  George Patton had great sensemaking and scared the pants off the German generals.  He was also insubordinate and bad at relating with his troops or commanders.  Meg Whitman took the chaos at HP and used her sensemaking and relating skills to improve the organization.  Not any of the leaders, I cited were “perfect.”  They were flawed and human.  They were good at certain things and delegated everything else.  It is why I think Omar Bradley was the best thing to ever happen to Patton. 

As a leader and scrum master, we need to accept we are imperfect.  I excel at sensemaking and visioning.  I will admit my shortcomings. I struggle with relating and inventing.  Only by acknowledging these vulnerabilities can we build trust, and to succeed trust is essential.  We also need to accept that each leader is incomplete.  Some will hide behind the mask of command, and other leaders will feign equal competence in these four areas of leadership. 

I have a different vision of leadership.  It is one where the masks fall away, and smart people work together for a common goal with a sense of trust.  It may be a little touchy feely but if it is good enough for the Harvard Business Review it is good enough for me. 

Until next time.


Monday, February 19, 2018

It is worth it!

The work is worth it.
I have been doing plenty of reflection.  I blame the dispiriting winter season in my hometown of Chicago.  The cold winter nights force you to confront your past and ponder your purpose.  My friends and social media contacts are asking me plenty of questions about my weird profession.  These kinds of existential moments make me want to do a little explaining.

I joined the agile reformation in 2009.  I was working as a contractor for a family run medical supply company.  I was thoroughly miserable.  I had no job security and little hope. I spent each day grinding out code for capricious people who treated everyone not family as medieval peasants.   Family disputes would boil over on to the sales floor, and anyone caught in the crossfire could lose their job.  It was such a dispiriting place to work.  I witnessed the ten-year-old grandson of the founder tease a salesperson saying, “Daddy says you are fired.”

In the middle of this night of the soul, a project manager decided the team should try “agile.”  It began with daily stand-ups and doing releases in two-week chunks.  It ended with unemployment.  The project manager left for a better job.  The IT Director realized I had more credentials than he did so I was a threat, and it made me expendable.

Between job searches, I did research and the more I learned about Agile, the more I realized it was a better way to lead software projects.  I also realized that the concepts while simple to explain were hard to implement.  Thanks to the Agile Manifesto and the early proponents of the scrum, there was a way to perform technology work without abusing people and providing better value to the business.  I would spend the next four years as a developer spreading the word about this new approach.

Things finally came to a head when I left my last role as a senior developer and became a scrum master full time.  I was no longer some developer mentoring others.  I was leading other teams and setting an example.  I thought I was ready.  I was wrong.  Over the last five years, I have been tested and challenge in numerous ways.  I have succeeded in public ways and failed in equally public fashion.  I am not the scrum master I was five years ago.  Everything I have learned along the way has made me better.

I keep thinking about a quotation from Dave Burgess I tweeted out last week.


The last nine years of my agile journey have been challenging, but it has been worth it.  I am a better leader.  I am a better developer.  The software is getting shipped on time, and the office is a little less capricious.  I do not have entitled ten-year old’s threatening to fire me, and the business community seems to be catching up to my way of thinking. 

This hard journey is probably worth it, and I am proud to be sharing it with you.

Until next time.