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!