Don’t Undermine Agility

In the book, “Drive“, author Daniel Pink talk about the primary underlying motivators of people based on research. He indicates that these are:

  • Autonomy: The desire to direct our own lives
  • Mastery: The urge to get better and better
  • Purpose: The service of something larger than ourselves

 

Each one of these elements can then be decomposed even further such as:

  • Autonomy – Giving an individual more control over where or how they work
  • Mastery – Providing recurrent opportunities for investment into skill growth or activities that provide both stretch and deliver propositions for the individuals or teams.
  • Purpose – Making the “why” of what they do highly visible or helping them see how their work contributes to the business as a whole or what impacts that they make through the work they do.

In my experience, these core ideals have always resonated me and they have been used within the culture we’ve built in my organization(although it could be more widely accepted):

Autonomy – We work hard to nurture the separation of the “what” and “how” of the work to be completed focusing the teams to have the freedom to have deeper ownership of the latter. We have balanced this by helping the culture find the value of conversation to find the best solution to meet the highest value. The best idea comes from where it comes from but no one has “carte blanche” to beat anyone into submission to follow their idea.

We utilize a remote work policy that is centered around being a professional and taking the work commitments seriously. Our teams are professional enough to understand that they have the ability to police themselves and have support from scrum masters and leaders in they see that someone is not pulling their weight or may bring it up for open discussion in a retrospective without fear. We expect notification as leaders so we can be responsible for knowing where our people are as a professional courteosy, that they have discussed it with their team and scrum master if they know they need to be offsite. We feel like this is polite notification as opposed to restrictive and teams seem to agree.

We use the general philosophy that “life happens”. I recall personally working jobs in which the expectation was that I took a vacation day for having an appliance delivered or having to take a sick day when I might be too unwell to make an hour commute but could have continued to contribute. By using this underlying idea, we communicate that we understand that people have life obligations that happen and we accept this and are willing to accomodate flexibility in where and when people work as long as we are still getting the work done in the best possible way and not degenerating into remote silos.

Always remember that if the tools and processes you are using carry so much overhead to ask a question, find an answer or interact effectively, an individual is more likely to make a decision in a vaccuum than take on the burder of the overhead of communication.

Mastery – We have realized this in several ways:

  • We provide recurrent week long hackathons to allow teams to focus their creativity on thinking about interesting ways to solve a problem or extend a product. This is focused around exploration of an idea and focused skill work, not product deliverables.
  • We provide to each and every member of our group a pluralsight account so that they can take advantage of learning within their schedule anytime.
  • We have designed our 13 day sprint cycle with purpose to account for a single day each sprint dedicated towards self-learning, skill building and growth. This provides and opportunity of almost 3 weeks of self learning spread out through the year.

Purpose – This is one that I think we could work on more but we do try and nuture product owners to really explain the end value gain that the business receives from the work that the teams are doing. This has often been promoted by talking a field trip out to the field to meet the end recipients of the work and allow them to explain what they do, how they work today and where their pain points lie. This often creates a solid empathetic connection between the team and the stories that they meet. Sometimes just understanding the history of the work being done, why it is done and what it does for the end customers can help them find connections.

Finding opportunities to allow teams and team members to connect to the business as a whole to learn about what it does outside of the product work would be a solid long term goal and is being developed by our Human Resources team within a learning portal.

One of my goals this year is to determine how we can utilize some of Diana Larsen’s ideas suggested in “Liftoff” to connect teams as early as possible to create deeper understanding and allow them to be directly involved in shaping the work such as story maps and user story decomposition as well as using ideas to connect them better to how their work connects to the business.

How you can undermine your own agility

Often, I have observed that people will do wrong things for the right reasons and wonder what happened to the organization that they created. The group they once believed in starts becoming less agile over time. Please watch and mitigate these issues should you see them begin occurring.

Autonomy – You begin stifling ways of individual work. If you begin to lose focus of where people are, what they are doing (especially in being asked by executives) or “situational emergencies” are seen as only possible to be handled onsite. You begin to predict the schedule based on ideas of when and are not open to the conversation of what as part of that equation. Your actions start communicating that you have a level of distrust in the work of teams as expectations and delivery are misaligned. You develop a culture that wants to “see people” more than it values “the work that they accomplish”.

Focus on schedule begins to overshadow value. You set dates in the sand for features based on limited information and begin eroding the team’s ability to provide you input into complexity and delivery to make value based decisions.

Mastery – There is an old joke in which a CFO questions a CIO about the money being spent on training. The CFO states “what if we train them and they leave”. The CIO replies “what if we don’t and they stay”?

In a creative field, the ability to grow with the industry and get better at what you do is often a core part of your career. It helps you promote, it helps you move to know companies, it often refines or grows your ability to lead either technically or otherwise. Becoming better, is a core value to being a creative worker. Sure, you may eventually hit a pinnacle in which you either trade those technical skills for a new skills or you get to a point where the languages become secondary to the patterns upon which they are built. You see languages as tools and the patterns of how they work become more transitive. Basically a creative career without growth means at some point, you will get stuck. The industry will move away from you. It does not need to sleep or play with it’s kids or spend time with its family, people do. With this being said, I cannot see how any organization that seeks to achieve any longevity with employees would ever consider not investing into employees. It’s a fool’s bet if you do not.

But there is a significant cost to this investment if using conferences, learning sites, etc. Which in the grand scheme of budgets is far smaller than people think, in my opinion. But there is something you can use and that is opportunity. Sure, it has the cost of allowing someone the time and freedom to learn and grow. But the pay-off of staying relavent and having employees who are constantly honing their craft is a good thing. Often time, bottom lines of budget can drive these. Look for every opportunity to keep continual learning alive through peer to peer sharing, local developer talks at lunch and learns or even reducing a team member capacity during sprints to allow them to learn. Find opportunities to showcase what is learned to your group as well as the business.

Whatever you have to do, do not allow obstacles to cripple your team member’s approach to mastery.

Purpose – General George Patton was quoted to tell his troops “Better to fight for something than to die for nothing” in terms of his deep patriotism. Teams and team members want to know that they are doing things that are impacting someone.

I have often said that my affinity for public sector organizations has been because “I would rather create a product that helps a secretary do her job a little better than to make a 10% profitability increase for a board of shareholders I never see; even if they give me a bonus in the process”. Maybe it is because I started in the social work sector before I moved into IT in business or maybe it is because the work holds less meaning to me personally when the measureability is based on profit alone.

In general, people want to do good. I have never met an employee or a team member in my entire career that came to work and said “I am going to do the absolute worst job I can possibly do”. They may be incompetant, poorly trained, not a team player, above their head, etc. but they did not intend to do a bad job. I often remind teams that perform legacy work who complain about older code that many times the developers who wrote that code were doing the best that they could with the tools that they had and within the abilities they possessed. They were just trying to get a job done and help someone. They did not intend to write code that they expected anyone besides them would ever support, let alone, complain about.

I recall being part of a team building a system that at a certain point we began calling it the “Titanic” as we joked often heard the ribbets pop as we scraped along the iceberg. The project scope grew uncontrollably and it became death by committee with each person fighting for their individual wants and making it difficult to get any one thing of value completed. In the end it became a bloated system of 80% features.

The reason I mention this project is that it took the team a LONG time to become frustrated even after the chaos started because we believed in the underlying mission of what the system was going to do. It was targeted to help kids. And help those people helping kids. It was going to ensure that they had better care, they got connected more openly to services and community. The vision was amazing and each and every team member was on board. We watched videos showing vaporware and shed tears at the good we were setting out to accomplish. We were connected to something larger than what we did because we knew how it fit into the world that it would be released to. It inspired us, it elevated us, it pushed us, it connected us. That vision drove us even when we as technical professionals should have know that the end was near as we understood what the purpose of the work we were doing was.

Disconnecting your teams from that purpose is a mistake. Sure, we have systems that are like “hello, this is our accounting system. it handles our payroll and benefits”. But what is the purpose of that system. For a team, this is the system that ensures that people are paid in a timely manner, insurance benefits are kept up to date and vacation time is accurately stored. Without that system, we couldn’t pay people, people could not take vacation and if sick, people might not have insurance if inaccurate information is stored. It helps us apply raises and bonuses that pay for the needs of ourselves and our families. The people that use this system do not ever want to be the ones that have to email everyone to tell them they are not being paid and rent and mortgages are late, etc.

Sure, payroll is dull to me, but it has a purpose, a need, a vision and a connection to the business. If a team is being asked to do something on a payroll system, the “why” is important. Are we speeding up a process? Are we adding a new feature? Are we making a problem go away? Are we allowing people to do something easier or better? Understanding this, can create a better connection for the team to do the work. Reinforcing these things with personas, story maps, etc can even inspire them.

Don’t decouple the “why” from team work. Don’t reduce it to “cause Bob says they need this”. Understand the why. Help them understand it and form a connection with it. Taking the time to do this will allow you to continue to remain agile and continue to support a quest of purpose for teams and team members. It will allow they to understand the business terms, frame questions in business ideology and connect to d the end goal they are trying to achieve.

Final Thoughts

I decided to write this article as I reintroduced to the concepts of Drive in some reading I was doing lately and thought about how we apply or should apply these ideals in an organization. They are some good core concepts upon which to build an organization that resonates to the base needs for people (and remember those needs may be broadly unique as autonomy for one does not mean the same for others so think broadly about what avenues you support and what you reject.) and how these items can become corrupted as you introduce less agility or embraces practices that work against their nature. It’s not to say that experiement and reflection are not a great way to see the impact of things. Agile is all about, I am all about it. But be open to impacts of things in a organizational way and don;t be afraid to fail or be wrong. Be an organizational scrum master and protect the teams and team members by protecting those things that helps keep them focused and productive and meets the underlying needs. Remove impediments and reflect often. Be open but be vigilent…

Stay Agile!

 

Advertisements

Find the value in planning

I decided to post this today as I had a conversation with a colleague who was struggling with the concept of velocity what it means, how it is applied in terms of sprint planning. He was struggling with a product owner using velocity to predict what could fit into a sprint and the team using it as the definitive line of what they could work on. As surprised as they were, I said, this is how velocity can be used although it should be seen as a radiator of information, not a definitive prediction for future work.

He was also very surprised when I told him that using velocity was dependent on how planning was approached as it might not factor at all. (insert head scratching here)

I explained that based on things I had learned from a planning and estimation course (thank you Mike Cohn) that there were actually 2 potential approaches that I was aware of when taking on sprint planning by a team.

  1. Velocity Driven Planning
  2. Commitment Driven Planning

The former, as the name holds makes velocity a primary point of measurement for determining team capacity while the latter uses available team member capacity as the point of measurement.

Velocity Driven Planning

This is the type of planning that is most commonly used, from my experience, and most commonly taught in scrum classes that I have attended. This is the process by which a team will determine it’s maximum team velocity based on past delivery to determine the level of commitment that they feel they can make in the current sprint. This is a view typically based on a historical perspective. That being said, velocity is helpful over the longer term when consistency shows the actual velocity of a team as opposed to the sort-term. And any disruption to that team means a potential change in their velocity. It is a radiator of possibility, not an absolute.

 Yesterday’s Weather

This is the process where a team may look a sprint or two behind (successes and failures are fine) and together determine level of commitment in terms of points that it can make commitment to based on that ideal.

Average Velocity

A team may look across several sprints, add the sum of total points delivered and divide by the total number of sprints to arrive at an average maximum velocity for the team. This will be used to set a maximum velocity for commitment by the team.

Capacity Driven Planning

This approach is much more focused on the amount of available capacity to each team member to meet the task  obligations so that they can apply this capacity to the items when decomposed to determine when they feel “full” as a team in relation to the overall hours they can utilize.

This process uses the following process flow:

  1. The team members determine how much capacity is available to the for the sprint. This can be determined by factoring in capacity for organizational overhead (meetings, personal time off, etc.) plus a projected maximum timeframe for unplanned work (such as support responsibilities, emergent tasks not identified or other items that may come up; as we never want to plan for max capacity typically) subtracted from the available determined timeframe for the sprint.
  2. The team will select a story from the backlog with the highest priority and decompose the work into the basic tasks that need to be completed to deliver the story and attach an estimate of the amount of time projected to complete the work in hours.
  3. The team members will take the decomposed items and apply it against their projected capacity (if development work the developers may need to discuss how the time applies across multiple people with same domain specialty). Once deducted, they now have their remaining capacity and repeat steps 2-3 until they have filled that capacity close enough that the team members are as full as the team can carry for the sprint. This will not always be the case for every team member.

This approach is focused more on the short term as opposed to velocity as it uses a projection of time over the next sprint period and the capacity of the team for that sprint work. Using this as a baseline after the given sprint would not be a good idea as the first step should be that the team members calculate the available capacity before each commitment.

This approach can be much more time consuming as the team is decomposing the work as it goes along to measure each item against remaining capacity before it makes the commitment to the given story. You have to be vigilant that a team does not get caught up into so much perfection of task decomposition that they make this meeting long, painful and less productive.

Which Should you Use?

Get ready for the answer you will love to hate.  It depends.

If your organization has team members not really following a focus of scrum or they have them handling other responsibilities, then capacity planning can be really helpful (and a savor for those that think the developer who can focus 1 hour a day has 8 hours to work on a product).

If your team velocity is all over the place or you have a sense that the team has fallen into a comfortable groove and never pushing themselves because it’s “easier”, maybe capacity planning is something to try.

If you want to find that sustainable pace that allows your team to use past information to give them insight into a future prediction, velocity can certainly help you do this.

Do you have a product owner that thinks in terms of features and not in terms of sprints? Either of these methods can assist you to help them understand how to create that bridge of trust with the team to understand what goes into what they are asking to accomplish.

A general rule of thumb is that if you look at the velocity of a team you will see some variance over time (based on team member availability or unplanned work) so it is really just a guide. Using capacity, you are trying to apply a more concrete form of measurement to the work at hand (although there is room for error here as well as things take longer, unplanned work takes up more time, etc.) but it is based on what the person expects that they have available to commit in terms of the value they provide to the team.

What Have I Typically Used?

Most teams I have worked with have used velocity as it feels easier to them than to determine their capacity and fortunately I have been able to minimize the distractions they have from product focus. But, I would be open to change if needed or to experiment. We often determine capacity for team members (like leave, etc.) at my organization with them just so that we can make visible to the team the drop in team member involvement so they can consider how this impacts their commitment.

My Observations of Team Planning Meetings

What I will say is that often times, from what I see, teams do not utilize planning sessions to the utmost effectiveness. They tend to rush to commit, rush to decompose so that they can start working on building. It often feels as if they are just trying to put something down and move on. It is our responsibility to help them understand that this is a time to refine the understanding before the energy of work begins.

Some teams do not use the time of these meetings to discuss architecture and design much or talk about approaches. They merely try to identify the tasks, drop some numbers and move into the work. This is a failure on our part of servant leaders if they do not realize that this is a horizon for which they can better understand the work based on the known today. If using the general scrum rule of thumb for 1 hour planning and 1 hour tasking for every week of the sprint, these can be long meetings for some teams.

A 30 day sprint alone could be a full day meeting. Why not use it in the best way possible? I get it, I have been a technical team member and was ready to build but the greatest power I found from the team was that we saved time when we came together, discussed and white-boarded ideas BEFORE we ever leveraged code. We maximized the time to gain a shared understanding of work that we could reflect and adjust as well as understanding the items we would be building. Approaching our sprints in this manner allowed us to create a shared and unified approach even if the path to get there was evolving throughout the sprint.

One of the best comments I ever heard about sprint planning is that it is far less important to be precise in identifying each and every individual task for a sprint than it is ensuring that you understand the stories to be delivered that make up the commitment as a team.

Stay Agile!

The Code you Love to Hate

“No matter how hard the past, you can always begin again” – Buddha

In my work environment, we have a portfolio which consists of a large amount of older code bases for which the team members are responsible to support for the business. I have personally experienced in the past the difficulties of supporting a legacy (I’ll use that term here but actually believe any product that starts it’s lifecycle from stabilization becomes legacy) applications and see how it can be a struggle for team members that I lead today.

Older technologies, poor implementations, no real guidance or design patterns, etc. Sometimes it is a real mess. I recall one of my mentors in development relaying to me when I was learning early in my career that fixing a problem in legacy code is often like donning a pith helmet and traipsing through a dense jungle. At the time, some of things I encountered used to make me so angry at why a developer might do some of the things he did in the implementation and it often caused massive refactoring (with care) to make it more maintainable. But as I matured as a technical worker, I began to realize a few base things:

  1. The developer may have been unequal to the task put before him. He may have been asked to do something for which his skill level made him unequipped to actually do and he created this in the best and most logical way he saw fit to accomplish his job. Maybe that popular “off the shelf” program did not exist when it was built.
  2. I believe that no developer sets out with the approach “I am going to write the sible code I can create”.
  3. The tools and technologies (or the depth of knowledge of them) at his disposal may have not allowed him to understand some of the side effects of things done.
  4. Maybe they did not have any real code standards or design patterns under which they were expected to write code.
  5. Refactoring of code is a given. Any code that exists and extended is likely to need refactoring when changed. Nothing is perfect.
  6. Bugs exist in the world. There are no perfect systems and any complex system will likely have issues that are unaccounted.
  7. If deep dependencies are used (3rd party or other systems) it is likely the developer though in terms of the environment of the day, not that the code might outlive those dependencies or they might change before this code base did so.
  8. Even if it is “legacy code”, as the current developer or team doing that job today, you assume ownership.  You may not like the way it is written or find it difficult but the base fact is that you have taken on this code base as a part of your job.
  9. You are in control of refactoring and can, whenever possible, make things better for those who come after you.
  10. Instead of focusing on the negative aspects of the code base, why not (as a developer reminded me recently) utilize the boy scout motto and “leave it better than you found it”.

Actual Problems with older code bases

I know as a technical professional we all hate inheriting a messy or poorly designed code base. It really sucks to have to work on it, fix it and sometimes just keep it running as the technical world changes around it. I often describe some as neighborhoods in which I try and perform the least amount of interaction and then get out.

I also know that many organizations do not fully grasp the need of the “care and feeding” of code bases or the deeper understanding that software should have a lifecycle and die and be reborn or transformed. Many organizations I have been a part of would rather hear the “thump, thump, thump” of the old reliable software and not think about what happens if it becomes in a critical state.

“If it ain’t broke, don’t fix it” is a very common idea. I actually knew a major software company that ran it’s accounting and payroll from a mainframe Cobol code base long past it’s prime and even hired high dollar consultants long term to ensure it kept running each time it sputtered and dropped a dump in hexadecimal code.

But the cost of continuing to gamble on these large complex systems is risk and if understood by the organization, they would see the importance to mitigate that risk as they would any other risk to the business.

It’s like driving a 1965 Chevy Bel-Air car. As time goes by, maintenance becomes more pervasive, parts become more difficult to find and eventually you may not even be able to get them or need to have them custom machined to keep your car running. This car may be something you keep covered in the garage and drive only on Sundays when the weather is nice. But if like a core business system, you used this classic car for your daily commute, the expense of upkeep and the risk of failure become greater and greater as time wears on.

So what do I do? I am a little scared now …

You basically have 2 core options:

  1. Bite the bullet and replace the system in total or find a way to “cage and lifecycle”
  2. Use a legacy transition pattern to migrate the system to a more maintainable code base in the future.
  3. Cross your fingers and hope for the best.

Option #1

Replacing a large complex core organizational code base is expensive. It is a large scale investment by a company and may require a significant technical  and personnel investment to replace. This is a fact.

But, just like buying a home, it is also an investment that hopefully returns greater end results through actually taking time to ensure that the system still actually supports the business and does not have “dead zones” of features that people cared about or wanted 20 years ago but no longer need. It gives you an opportunity to think about how a system models to the current business. And even while recreating the system, you still must maintain the current system and managing the changes to that system can be a challenge.

You also could encounter the dreaded problem of “thinking in the old system” as opposed to thinking in terms of how the business works. This can be especially true when a system has been a core system. People stop thinking about what the business needs and relate it to more of what they currently have to maintain in the system . This can be especially risky in disaster recovery scenarios in which the business must know how to function without a system being in place. For many businesses, they never consider this issue (given the world of distributed servers and cold site switchover).

In short, if you take this route, the organization has to be focused and it may be painful but the goal is to create something (hopefully in a better designed way) that can be cared for over time and change over time. If you take this route, placing a lifecycle for the system is probably important as well.

Option #2

One pattern I have become very interested in comes from Martin Fowler. It is called the “Strangler Pattern“. I find this approach very interesting as it balances the replacement of the former system with the new system but utilizes a common set of services to supply both until the legacy system is “strangled out”. The idea coming from vine growth in Fig trees that Fowler and his wife learned about on vacation. The vines sprout in the top portions of the tree and grow and eventually take over and replace the host.

I am not deeply versed on replacement patterns but my assumption is that this is only one of many. If you are fortunate enough to have an application that did use an MVC pattern, you might be able to begin to replace pieces in place and minimize disruption.

Another approach might be to leave the data structure as is (although legacy systems are often rife with business logic in the data tier), build the new system on an MVC or MVVM pattern with a services layer and later refactor the data tier over time and adjust the models to utilize the new data source while moving the business logic in a more desirable tier of the pattern.

Option #3

As surprising as it sounds, this is actually a path that some folks take. Please don’t find yourself in this situation as all of the hope and good karma in the world is not going to pull your backside out of the fire when (and I say this as opposed to “if”) things go South.

Final Thoughts

I started this post as I think it is important as team members that have legacy application to understand just as we collective own the new code we create, we own the code that came before us as part of what we do. I think that it is important for organizations to understand that these code bases can equate to risk and should be mitigated as any other potential impact to the business and that there are many ways that we as technical and creative people can help move the needle forward.

And most of all, the statement given to me by that developer on a team that said “leave it better than you found it“(the Boy Scout motto).

I think that is sound advice, no matter what you do in your organization and should drive us all …

 

Scrum master tips – The burndown

I have been working with several entry level scrum masters over the past few years and have discovered that although they may fully understand the general ideas of rituals and artifacts of the scrum framework, understanding the underlying agile value proposition these things support. Gaining insight into how they can utilize them with continued effectiveness with their teams seems to not be something that many do not often explore initially.

So I thought it might be helpful to convey how I view these items and how they can actually create impact for you as a scrum master to up your effectiveness with the teams.

My personal philosophy when I became a scrum master was that my role was a lynchpin in the process overall and that by increasing my understanding and effectiveness of the roles, rituals and artifacts, I could become a better servant-leader to a team overall.

This is merely how I view and utilize these things and hope that they help you as well.

What is the burndown chart?

The burndown chart falls into a category for me to be viewed as an “information radiator. It provides information in a static way that can allow the scrum master and the team to view the current state of product work within the sprint. It radiates information that can then be consumed and acted upon. It is a great artifact for assessment and course correction as well as allows scrum masters to begin to see items occurring within a team that may not be readily apparent, even to the team itself.

It is a chart that is measured by taking the amount of overall effort to be performed (hours of work) and plotting it across an axis of the total working calendar days of the sprint. Often it is coupled with an “ideal line” that reflects the optimum burn of effort equally distributed among days. As the “task hours” are burnt down, it reflects where the team is in terms of hours remaining to complete within remaining time of the sprint.

A typical burndown might look something like this:

burndown chart

In this scenario, the team has 400 hours of delivery tasks over an iteration of 10 days. This reflects work that may be done by the entire team (coding, testing, design, etc) for the 2 week iteration. So, the ideal line is reflecting to the team that at an average burn rate of 40 combined hours of effort by the team that is projected to complete the committed work within the 10 day sprint period.

Typically  the burndown charts I have used reflect the days of dedicated effort and do not reflect periods of planning, review, etc as these are bookend ceremonies to provide sprint lift-off and sprint landing. The burndown is focused on the time where team effort is directed towards end commitment.

The basic idea behind this chart is that from an agile perspective the highest value is to be aware of the work remaining undone and not to remain focused on the work already completed. So the responsibility of the product team is to reflect the remaining hours daily to represent the actual burn of working on a given story.

This is a very brief and straightforward explanation of what a burndown chart is so let’s delve into the next level of how it is helpful, how we might utilize the information and look at some ways to interpret patterns we may see inside a burndown to better frame questions or make inquiries to the team to help them.

What does a burndown chart do for a team?

As I mentioned before, it is an information radiator to a team. It gives them a snapshot of the past brief period of work and tasks completed and a reflection point for the work remaining to be done within the sprint. This information allows them to reflect a current team state both internally and externally to convey where they are without a “direct status report” to others outside the team as well. Anyone looking at the chart can get a general idea of where the team might be even if they do not fully understand the chart itself. This, however, can also lead to bad perceptions as opposed to informational learning as we will discuss later.

It is incumbent that a scrum master fully understand the purpose of this artifact, the reasons behind how it actually works and to begin to see patterns of work or potential team dysfunction within a burndown chart.

This allows them to not only accurately convey how to use this information and its purpose but frame questions aimed at potentially keeping the team productive or assist the team to be actively  aware of the “first responsible moment” of when a product commitment might become in jeopardy.

Patterns of burndown charts

Visual representation of work often allows an excellent opportunity to the scrum master and the team to reflect on familiar patterns that can be a visual queue to certain information or team dysfunction.

The Ideal Line is merely a Projection

As a scrum master, if you have the belief that below the ideal represents the idea of “being on track” and above the ideal is “being off track” you are taking a far too simple view of the  information that the team provides.

The burndown should be seen as a reflection for consideration of current state of a product development print to make inquiry, not predictive like a project schedule. The ideal is merely a projection of all things working with no issues impacting the team. It is a projection used for comparison. Establishing the thought as a scrum master of anything other than this or reinforcing to the team that it means ahead or behind the curve is a bad precedence to set and can lead to future problems.

Effort Swelling

For instance, in the image above, the team starts on day one burning down tasks and within the next 24 hours begins drifting above the ideal. A simple view might create panic and say “HEY EVERYONE! WE’RE BEHIND ON DAY TWO. WE GOTTA DO SOMETHING!!!!” when the circumstances that cause this picture could result from many potential reasons and should be information we can use as a scrum master to reflect on and potentially frame questions such as:

  • Did the committed work had greater unknowns than the team imagined and tasks are emerging? Normal and very possible. Probably just something to be aware of and see how the trend moves within 24 hours or so. But a basis to have the team reflect on this data maybe as a visual cue to them in your next stand-up.
  • Is the team struggling? Is there a causation? Has the team experienced a drop in overall capacity from the commitment due to sickness, not accounting for a team member vacation, etc? Many modern electronic tools, such as Microsoft Team Foundation Services,  will allow you to adjust the loss of capacity by each team member and the chart will update to reflect this effort recalculated across the iteration.
  • Are they just stuck? Are they mentioning impediments in their daily stand-up? Is there something you can do to assist or coach them to self-organize around solving the problem through inquiry?
  • A common symptom of a potential team dysfunction is that the members are not actually “burning down” their hours. They are pulling a task into a working state and working on it until done, therefore reflecting the total hours when there is actually less to be completed and then moving it to done all at once. This can show work not moving and so the work remaining can begin to begin a swelling pattern. One way of getting some insight into the pattern is if you see large drops of work following a swell.

Effort Drops (“work falling off the cliff”)

This pattern may look something like this:

Burndown Chart 2

Some questions that might happen when seeing such a drastic drop quickly:

  • Was the work committed less complex than the team thought initially and they just hit a “rapid burn” (Go Team!)
  • If following a swell, is the team actually burning down the hours regularly?  Are they perhaps holding on to tasks and not updating remaining hours but just pushing it to done when completed? This might prompt a scrum master to look into this information that the burndown provides in combination with the sprint task board and use it during a retrospective for exploration of “what does this mean to the team”?

Again, the key takeaway here is that these types of patterns provide an opportunity to learn, observe and inquire to assist you as the scrum master to help the team remain productive towards meeting their commitment. This information can help you teach the team to use this information to get some insight as to what is going on either during the sprint or used for exploration with the team within the retrospective.

These are merely some simple examples of how this artifact of the scrum framework can be used. It is best to keep in mind the concept of how it reflects back information to the team. Many scrum pioneers have discussed “BVC’s” (big visible charts) of which this can be one to help teams reflect on their current state of work and make adaptations based on insight. I hope this blog post allows new scrum masters a new way to use this artifact and can help them assist their teams with better insight …

I often consider this quote when thinking of a burndown chart in relation to teams …

“Information is only useful when it can be understood” – Muriel Cooper

 

 

 

When Fear of Failure Strikes

“Failure seldom stops you. What stops you is the fear of failure” – Jack Lemmon

I had an interesting coaching moment with a scrum master today. He came to me with a dilemma he had for his present team. He has a new team that has a new senior developer on it and they are in the process of storming as a team. Given this state of team development, it is only natural that they are in a growth period.

In their prior sprint, the team had a plague of sickness spread across them and they did not meet a significant amount of their sprint commitment due to the unexpected loss in capacity. This significantly concerned them as when they reviewed their product at sprint’s end, the stakeholders who attended did not seem to understand what the idea of “undone work” was nor how it was typically handled by the team.

The product owner managed the stakeholders relationship well and explained how the undone work would roll forward to the next sprint as the highest priority (given that was still the case) and be addressed by the team. But the team became very worried about the perceptions of the stakeholders. Fear of failure had reared its head within the team.

The scrum master, being conscientious about this engaged the team as based on some severe inclement weather had forced them to see the possibility of a failed sprint looming again. The team had asked, maybe we should change the process to only demo those features to the stakeholder that actually work. Being a relatively new scrum master, he wanted to explore this with me to help guide them. He came and met with me and told me what the team had suggested and admitted he felt uneasy about this change but wanted additional guidance. Instead of “giving” him an answer, we explored the situation and circumstances surrounding this request once he related the situation of the undone work in the previous sprint and the feeling of dread by the team with their current sprint.

I asked a few questions of him:

“So the team feels confident that they will not complete their commitment”?

“Do you feel this is a reaction to a fear of failure”?

“Do you think the compromise to hide this undone work compromises the agile value of transparency”?

“Is this the first responsible moment to speak with the product owner to indicate the work that will be undone so expectations are set with them rather than surprise”?

These four questions helped him find his own answer. He realized that he did have time within the sprint to engage the product owner and set the expectations of him and in doing so release the pressure of the team without finding some method to place transparency to the users into the shadows. He determine he could help the new team more by helping them understand that failure is opportunity, not a point of suspicion, ridicule and derision. He found a solution within his own problem by thinking through his problem so he could help his team do the same.

As a result, he engaged the product owner to indicate to them the work that may be undone so that they could discuss this with the team, ensure that the items worked on were the highest valued among the undone work (which they were) and kept the issue of fear of failure as a point of opportunity as opposed to the crushing blow of defeat. He helped them find relief and refocus on the things in progress without continuing to worry about the items that they knew they might not achieve.

In the end, they completed their commitment as it was the fear of failure to the stakeholders that made them concerned not the reality of doing so. They were so caught up in not appearing to be failing that they saw the loss of capacity as a reason to react. He guided them to understand this principle as well as one of the “first responsible moment” so that they could create transparency and strengthen the openness and relationship with their product owner. He turned this situation born of fear into one of working more closely together to succeed.

And he did so by just stopping to consider a few questions to allow himself to explore the possibilities. Fear of failure is a real thing with teams, especially teams that are allowed to select work within capacity to deliver as they feel they are driving the work. But failure is an opportunity to learn (although I know many executives who may not agree).

But through inspection of the underlying reasons behind this fear we can often find ways to gain clarity and help shape it into a learning point and create stronger relationships and stronger teams.

We all fear failing. But it does happen and often as a result of things far beyond our control or sometimes when we are doing everything right. So when this happens, it’s easy to just react based on this but the more challenging thing is to examine the fear and determine if our failings can be something that makes us better moving forward.

 

Team Metrics

“The past cannot be changed, forgotten, edited or erased. It can only be accepted.” – Unknown

Let’s Define some metrics!

I had a conversation with a relatively new scrum master recently who was working to help establish some base level team metrics for their organization. They had made the journey to scrum from the role of a project manager and seemed to really transition the mindset of driving to create an environment of trust and transparency within a team and shunning the ideas of controlling the time/budget/scope and “resources” (word I hate when it comes to talking about people) viewpoint of traditional project management.

So my initial question was “who are these metrics being designed for”? This is something we often do not consider. There is a different need for reporting transparency and one to help teams improve. If oversight is the driving goal then the assistance to the team may become minimized. If the goal is to create metrics that are learning opportunities for the team or generate insight for a conversation then the construction of these may be much different but may provide less insight into what management may be seeking.

All metrics are not created equal …

Except, when it came to metrics it seemed. Most of the metrics they were developing were centered around trailing level metrics (lagging metrics for those who are KPI inclined) for the team. A lot of the focus was on the past as a predictor. So I raised the question; “why are you so concerned with the past” in terms of metrics?  They explained to me that this is how he could help the team improve by knowing where they failed or made bad decisions beforehand. So I asked again “given the dynamic nature of iterative development, how can you ensure that the same cause will generate the same effect”?

We discussed in detail that they were extremely proud of was the tracking of “estimated” versus “actual” hours on tasks. They worked really hard to convince me that learning the difference between the two would help them more accurately estimate the work to be done. I let them go for a while and then I had to call bull%^#$ on this.

In my opinion, the only way an “actual” at a task level will be a predictive metric is if the the same circumstances occur exactly the same way the next time. Estimation is just that. It is not predictive in nature, it is a best guess based on the knowledge known at the time. And before anyone says it, you can make a better estimate by reducing the unknowns but you can never eliminate the unknowns.

If I have a headache,  I had road rage on the drive in,  I had more meetings than normal, I volunteered to help someone, I was tired …  A whole lot of things could impact the differences between my estimation and delivery.  So in my “estimation”, this metric is a “narcotic metric”, it tends to make you feel good but it actually could be very damaging when using it.

And what if we do know this information? The key is to be able to take information learned and make it actionable. How do we do that? Send an email and tell the team to estimate better? Begin to question their estimates? Make them sign off? I cannot see how you “use” this information to help them actionably improve.

Refinement Metrics

One type of metric I always recommended for consideration is one I consider a refinement metric. This type of metric is designed to allow the team to perform self-reflection on a recent event given the context of more knowledge and apply that knowledge to a past decision. Instead of comparing the past to the outcome, it asks “given the things we learned, do we think we made an accurate assessment of the work”? Sounds similar but with a couple of differences. 1) It’s never at a task level. 2) It’s a team level rather than a individual developer level as the goal is that the team learns to become better as a team, not as just an individual member.

So what I suggested is something we would often do as part of a retrospective with a team. We would examine the stories for the sprint just delivered and look at the assigned story points. Then we would have a discussion and asked if given the knowledge today, would we apply the same story points. This typically leads to a discussion of dependencies, issues, etc and the team centers pretty quickly around a “stand/raise/lower”. This does not help them get better in defining the individual number itself but helps them reflect on this type of work and the hidden complexities that can be present to determine questions that they may ask themselves or the product owner to create a better consensus around an item in the future to the potential complexity of the work.

Just in Time Metrics

One metric that I have read about after working as a scrum master that I liked was a daily vote of confidence. If you have ever been in a U.S. hospital and had surgery there is a common tool used by nursing staff to determine the level of pain you are in to report and administer treatment. It is called the “pain assessment tool” often and looks like this:

pain-scale-chart

This allows the patient to quickly indicate the level of pain that they are perceiving and reflect this to the nurse, doctor, etc. The blog post I had read (which I wish I could recall the link) suggested using a similar scale for each team member to allow them to forecast their confidence level to meet the current sprint commitment. This allows each team member to express their confidence on a similar scale from “Yep, we rock!” to “Hey guys, I am really, really worried where we are right now” so conversations can be had to determine what’s going on for the purposes of communication at the first responsible moment or to allow the team to swarm around and issue, etc. A simplified version of this has been used by teams that involved “Roman voting” (thumb up affirmation, thumb down condemnation) as well. This type of metric gives you perception of the current state of work in a very real form and let’s you make it actionable. This is often easier to use than seeing potential patterns within a sprint burndown (which is another post).

So just as I asked this scrum master, I ask all of you. Do you have metrics? Who are they created for? Are they actionable or are they just data? How do you use them? Are they actually helping you and even more important are they bringing value back to your team(s)? How do you know?

I leave you with a quote about the importance of knowing why you are actually measuring something …

“Remember, what gets measured; gets managed” – Peter Drucker

Let me tell you a story …

“It’s like everyone tells a story about themselves inside their own head. Always. All the time. That story makes you what you are. We build ourselves out of that story.” – Patrick Rothfuss, Author

 

How did it all start?

My journey started with a personal quest to transform the way I work and delivered value. I was deeply embedded inside a V-model culture in which the end result not meeting customer expectations was typically blamed on the customer.

I started my journey by annoying my manager to allow me to create a pilot project (of little significance to appease me) for my organization after reading about the scrum framework. I knew that this was going to be the wave of how organizations began to work and saw a clear path as to how it could benefit the government sector. So I prepared, I studied, I learned, I asked questions and became immersed in how this worked.

I was given a small team of what I will call “the usual suspects” which were made up of long term employees who were pretty adverse or afraid of change, an assigned “product owner” (who they decided a project manager fit the bill) and a stakeholder who had no idea what I was trying to do. My goal had been stated to conduct this pilot and deliver my findings on if it could benefit this public government organization and what type of staff would be needed to sustain it. So here I was, new team, no idea what this crazy person indicating he was a scrum master (with no experience) asking them to work in a new way in which they would drive their own work, a product owner who needed to understand the role and learn to “lead a team without authority”. This seemed like a real challenge. So, I was all in.

How I got started with my first team …

I started by gathering this new team together and explaining very simply the framework, the roles and rituals and how sprint cycles worked. I was met by questions such as:

  1. What do you expect us to be able to deliver in 2-4 weeks?
  2. Where are the requirements?
  3. How will I test an application without requirements?
  4. You want us to sit together and work collaboratively? What about my cubicle?
  5. What do you mean we determine the amount of work we will deliver? Who manages the project?

And many, many more. I addressed each question as best as I could, remained confident and worked to gain their trust. I assured them that I would be right there with them and help them work through any problems as they arose. I assured the product owner that I would work directly with him to become “team ready” so that he could build his product.

Everyone left the meeting unsure of what lie in front of them.

The initial process …

Needless to say, it was tough the first few sprints. I had to guide the team to understand what “potentially releasable” meant. I had to teach a project manager an entirely new set of skills and way of working and how to establish trust in his team to turn his needs into product without use of command and control. I had to reassure stakeholders as they saw partial software being built out along the way. I had to teach a team, how to conduct a daily stand-up, use a task board and burndown hours. I spent countless hours coaching nervous team members who were so far from the way they worked that they were doing this amazing thing that had never been done before.

Although there was a lot of fear over how they were working, through coaching and support they began to move as a team.

The end result and learning

In the end, the product delivered was a success. It was not that it was a highly prized award winning software package that carried the value that we would have liked but it lit a small spark for some people as to a new way to work.

This team had learned to work together, enjoyed the work they were doing and felt in control of delivery once they found their rhythm as a team. The newly anointed product owner saw benefit in the way he worked in this situation and began asking me how he could “be more agile” in what he did. The stakeholders were happy with the end result and the software was delivered in weeks instead of months.

So, I sat down and typed up a summary of the experience, the overall process and how it shifted roles and needs within the organization, an estimation on what type and level of staff would be needed as well as a recommendation to start small and grow over time as opposed to a large scale shift.

The report was presented to the director of the organization who summarily dismissed the approach indicating “we are never going to do this” (firmly believed in the waterfall approach). I think he may have even thrown it in the trash.

Although disheartened, I knew that this was the right thing to do, especially within the government sector to bring more value through focused iterative work. So, I began to plan my exit from the organization in search of somewhere that I could actually make a difference.

The Partnership …

Coming off of this pilot project and more determined than ever to see this way of working take a foothold. Some leadership shifts had begun to occur and I knew of one other individual within my group that seemed to work slightly differently than the standard PMO. His background was in product management and he treated his product in a different manner than the other project managers. So I approached him and told him about the framework and said “I think you should look at this, you are doing about 80% of it now. You just need the discipline of the other 20%”. He read through it and was intrigued but struggled to get through the scrum guide as it felt like it was more engineering focused. I referred him to the agile manifesto upon which it was built and these values had a much more resonating effect. He became curious. He was a marketer and I had a vision for working in a better way. We were the perfect storm brewing.

As we were both ready for the next challenge, we created a skunkworks project with a new assistant director sanction. We created a team room and sat about to deliver the first product of larger business need using scrum. My new product owner new of a 109 page report delivered to the Commissioner that outlined business related projects (both in planning and “in flight”), their timelines, their progress, etc. It was in an effort to support his regular visits with community leaders with a group of organizational leaders so that he could hold conversations about items specific to the area and be aware of current status as he held the conversations. This report, we later found, had never been looked at by him.

My product owner had the idea that we should produce an interactive map application that could be used on a mobile device so that executives could review this status anywhere and use location as a way to get to these items prior to meeting without going through the hoops of asking a cadre of other people to compile and sanitize the data. I believed that domain data should remain where it lives and that this application should be decoupled from these core business systems yet reflect real-time changes to the data. This had been the debate for many years within unsuccessful committee after committee of how you “connect” the information into a  unified view always resulting in “it cannot be done” or using mechanisms to scrape data from one system to make it visible to another. The problems were:

  1. Once scraped, the ownership of the data in question became transferred to the new owner who was unlikely the owner, therefore would not recognize errors within that domain or ensure that it was accurate.
  2. This was something that actually forced a cross organizational work effort within the business and a base level understanding of owners and consumers of data.

Our theory was through the building of this application we could do several things:

  1. Eliminate a 109 page report that people rarely looked at.
  2. Create a locational context to the data making it more meaningful
  3. Solve a long standing business issue into connecting multiple domain sets of data and giving them visibility.
  4. Create a lightweight tool that since it did not create data but use the data at rest, would allow for quality control in terms of how the data was actually reflected.

So my experience of all of a few months and my colleague of zero months sat about to do the impossible at the time. Create a product (which was not the term used, it was always project in our world coupled with plans, committees, governance, etc) built using the agile framework of scrum with a small but motivated rag tag bunch of team members wanting to do something different and believing they could bring value to the organization. Sounds like a tall order. It probably was. But why was it a good choice?

  1. The product we chose had immediate business value and visibility to the highest level of leadership. It could be a product they would actually use.
  2. It solved organizational problems by connecting disparate data sets and visualizing them in a geospatial context.
  3. It rallied a team. Teams were being demoralized each and every time they worked so hard on a product for many many months just to be told “this is not what we wanted”.
  4. It was focused on value, transparency and visibility. We welcomes anyone to observe how we worked, what we were doing and communicated openly and often. We littered our area with BVCs (big visible charts) indicating who we were building the product for, what the features were and the current progress.

So after putting some solid time into product planning (understanding the need, identifying personas, creating a vision and decomposing high level needs into features) we started with a cross functional team of developers and I played a dual role of scrum master and tester (which I do not recommend of possible). Being cautious, we selected a horizon of 30 days for our first sprint (which probably ran slightly longer as we were learning).

At the end of this cycle, we had a releasable product. Did it do everything wanted? No. Was that the point? Yes.

We demoed the product for the director (who as you recall said we would never do this) who was looking for a win with management. As my PO reviewed the features, the director asked several times “and you built this in a month”? He had no idea that this level of work could be accomplished like this, without the tomes of documentation, the endless committees and death-march approach of a 9 month waterfall effort.

Excited by what he saw and eager to show his leadership value to the executives, he arranged a demo with us and the COO and CFO (even though I am unsure of he understood what had been done or why). Although the first iteration was primitive, they saw the value of this product and method of solution delivery. A rapid innovative solution meeting a business need by people who wanted to respond to change. They immediately scheduled a meeting for us to demo to our commissioner.

Demo day with the Leadership Team

We arrived and setup our demo for the room. We had gone through how we would demo the features and planned to show how it worked across multiple devices so that it could be accessed anywhere. We, perhaps naively, assumed this would be IT, the COO and CFO and Commissioner. The room filled to the seams. Apparently we had stepped on a lot of toes of people who had been promising a solution to this issue for years. They all stopped in to see and, in my opinion, find that one gaping flaw that proved they were right in the impossibility to solve this. Our top leader entered with his staff and off we went.

I produced the 109 page report that this replaced and was immediately struck by the confusion on the commissioner’s face. He had never seen it or if he received it, never read it as it was like a car manual that was designed for the people doing the work, not to help people understand. We continued our demo and I handed him an iPad with the application displayed so he could play with the application and replicate what we were doing on screen. He became more engaged. We were excited and wrapped up the demo for the room.

With a brief pause the commissioner asked “who told you to build this”? We replied “no one, we knew it was an open question that the business had and we wanted to provide value”.

He then proceeded to do what I would call “beat the application with a proverbial baseball bat” telling us all the things it did not do or he wanted it to do. The PO and myself hung on his critique and I scribbled notes so we could process them later. The director looked like we had just shot him in the middle of the room. His perceived “win” seemed to be going south and here were the two guys to blame.

Once the review finished, the commissioner rose and said “I’ve got another meeting but you guys are 100% on track” and left and all of the spectators (many of whom probably felt we got what we deserved) filed out leaving the COO, CFO and IT staff behind. The C level executives apologized for the reaction and the IT director seemed to be disappointed we showed “incomplete software”. But we responded in a way that shocked the room …  “This was great! We now know what he did not like and we can pivot and begin adjusting those features”. We explained that this how this worked. We review regularly with stakeholders, receive their feedback and adjust course as needed. They may have though we were a little nuts. I know a lot of the IT leadership did but with the excitement of the executives, we were given a reprieve to continue.

Within one more 30 day sprint, we had a version that met the needs and it was being used in the field. It was the fastest delivery ever done from a team of 3-4 as opposed to 5-12 over a 9 month period after 9 months of requirements gathering beforehand. We held conversations surrounding value and need, not features.

My PO was made CIO following the success of the product and asked me to stay on and transform the organization to work like this on every product. 4 years later and we have 4 scrum teams, 5 product owners and other pockets of agility. Even our own HR for the organization has become trained in kanban and uses it for their HR projects. The business extrapolated the idea of the scrum team to create “business studios” made up of all of the team members needed to complete a business function for a core business line.

How I planned to Build Something New Here …

When the PO moved into the CIO role he asked me to stay and help him build something new. I agreed under 2 conditions:

  1. I needed to be able to always call BS when I sensed it.
  2. I needed to be trusted and left to build it right.

He agreed (although he may have thought I was a bit nuts, and still may).

First, I knew I could not do this alone. Although I had a significant technical background in all aspects of software delivery, I had to follow the advice of “getting the right people on the bus”. So the initial team for this organization was hand picked and recruited. They were either excited to do something new or brought in superior technical skills and strategy to build out a solid technical architecture. I remained personally involved as a scrum master and tester (as we did not have much depth) and we stayed strictly adherent to the framework (look at the Shu-Ha-Ri principle).

Once I was able to move into more of a leadership role, I set about doing a few things that I think, although small, made a big difference.

  1. This new organization would be align as flat as possible to encourage self-management and self-organization. Everyone reported directly to me to support the people doing the work determining how the work would be done. This did not change until the group had significantly grown and it became necessary to add a layer.
  2. Continuous learning for the group would be core to the values of the new culture. We identified a great online technical education resource which we procured for every staff member and the idea of a “lab day” in which they built upon their own skills following each sprint became standard practice.
  3. The idea of team protection and focus from distraction was also a core principle. We minimized disruptive impact to the focus the teams and encouraged, coached and empowered them to take commitments seriously by ensuring that the people doing the work indicated the commitment of work that could be done.
  4. I hired a couple of eager team oriented scrum masters to be servant leaders to the teams and help them mature.
  5. Ensuring space was available for the team members to innovate and exercise personal creativity. Outside of the standard lab day within the cycle, I self-funded and piloted a hackathon which is growing into a larger and wider event for the broader organization.
  6. Hiring became focused and central to our growth. We broke out of the typical mold of the state process in which an applicant performed a 1 hour interview in which they regurgitated their resume and convinced you to hire them. We implemented 3 hours interviews that combined not only behavioral based questions to gauge how they had responded in the past to situation or might do so as well as a 2 hour technical interview in which the expectation was that they demonstrate the skills needed to do the role for which we were hiring. This has been something we have maintained focus on changed over time as opposed to making it a standard approach. I strictly adhered to the rule of “hiring the right person” and if they did not show up, I hired no one (much to the dismay of my leadership as the public sector hiring process can be cumbersome). I truly believe that this helped us create sustainability by making good hiring decisions.
  7. I placed equal focus and attention to the cultural and technical growth aspects of the group. I hired people that were “culturally additive” in terms of value and with the help of strong technical leaders we defined and adhered to an architecture complete with design patterns, branching and merging strategies and promotional process. Defining this initially but leaving it to the technical people to grow has done well. I tried to be very intentional to create some growth paths by not hiring for every position so that people felt they had to leave to get ahead.
  8. Instead of overloading a lot of processes (outside of the rules that were outside my control in the public sector) I imposed a litmus test for decision making composed of (2) key elements of consideration. Is what we are seeking to do “reasonable and responsible” to ourselves, our team, the citizens, our organization? If it met this litmus test and we understood and accepted the personal responsibility of the risk, remained transparent to those involved or impacted, the people doing the work had the complete freedom and support to make good choices without committees, work groups, management hierarchical approval, etc.
  9. I established the idea of creating tribes within the organization composed of people with a passion to solve a problem that they created themselves and managed. This applied to everything from how we celebrated birthdays to our recurrent staff meeting to process improvements.
  10. Everyone had a voice. Starting with everyone reporting to a single point it was easy to establish that anyone had the right to speak out. I reinforced this to staff by being an advocate for meritocracy, not democracy. “Good ideas come from where they come from” was the guiding idea.

In doing all of these things, I learned a lot. I challenged a lot of preconceived ideas of how people operations worked and how work got done. I have to say, although there is always room to improve and grow, I am very proud of the teams that are here today. I have had a few people move to new opportunities (always in a positive way) and seed groups of their own or seek to take aspects of the culture and apply it to new organizations.

While I have always hated to see people leave, I treated this as a good thing that they were growing and not dwelled on any gaps it left behind, which I think has been encouraging to them and not created undue organizational stress. So many public sectors operate in fear of “that one guy” leaving as they carry so much legacy knowledge. They do not stop to realize the problems is in the silo of knowledge as allowed by the organization, not the person themselves.

So why did I share this journey?

Some might think it is for the purpose of braggadocio. Nope. While I am proud of where I am and where this organization has grown, I see miles of potential unrealized before us. I think we are where we need to be today and hope we continuously inspect and adapt to get us where we need to go to become truly high performing.

I have heard many stories that amaze me on how people shaped their work world and I take personal pride in what I do and am impressed by the strides of many others. I have tried experiments that have succeeded and some that have failed miserably. I am very fortunate to be in an environment that has allowed me to do this as they know that I am aware of risk without sacrificing the need to experimentation. I truly am grateful for this opportunity.

Personally, I am grateful for everyone I work with from the most agile person within the organization to the person that is struggling just to figure out how they fit in the agile space. The former because they focus on value as a driver in the way they work and the latter because they want to learn, adapt and grow most likely or find the way they can connect with something different.

I take pride each and every day knowing my teams are in control of the work they do, take their commitments seriously and work to deliver quality products to the best of their ability. I take pride in seeing the depth of people we have and how those differences make them a more solid team as a whole. I am humbled by the fact that a great deal of people took a chance to try something different and trusted that we were building something great. I take pride in building an organization in which and every person has a voice in their work no matter their role and that teams are protected when they fail from being vilified and  are asked to use these as learning opportunities. I am proud that my teams know the value of the “first responsible moment” when encountering problems and raise the flag to draw the attention when it happens so that risk is managed in real-time as opposed to being based on a risk register outlining risks that may or may not ever occur.

I spoke at an agile leadership summit about 6 months ago and one of the other speakers said “you should tell stories more, you have a knack for it” (unsure I agreed but appreciated the compliment). I actually did tell the organizer that if they had a rocking chair available, that is was best not to place it where I could sit when giving my talk or I might keep folks for a while. Yes, I love to share things with others. Perhaps it is in my nature and wired within my regional DNA in general.

The reason I share  and this story is that I want people who may be struggling with a transformation or even just getting started to have hope.

Hope that you personally can do something different and affect change. I helped drive the implementation of agility in the most unlikely of places at a time when “death marches” of project failure were accepted in the culture as the standard practice of work and the value add by IT in general was viewed as very low by the business. From this small product, we transformed an organization and a culture and started a broader conversation that continues today. I often tell people when I started this conversation, I was the only person in the room (which meant a lot of talking to myself). I recently attended a meeting where 10 people engaged in a conversation of how to apply agile conversations more broadly and have coached, mentored and shared this story with a lot of folks over the years.

I alway recall a quote that inspired me early on from Mike Cohn.

“Agility is not something you become. It is something you become more of …”

If you’re stuck now or things are less than optimal. Stop. Take a breath. Figure out where you can pivot and where you can persevere. If you are unsure where to start, find that thing that you can make valuable and start “starting”. Be as agile as you are able to be given constraints and then push to become more agile. Learn from failure, embrace feedback, push yourself and do not compromise or collapse in the face of adversity. Show people a new way to work and build a culture that drives to empower and trust those doing the work, not operating under command and control.

I am going to end this quote with a passage from Apple’s “crazy ones” ad campaign created by Rob Siltanen and hope you all stay agile!

“Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently.

They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things.

They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.”