If Your Up-Front Planning is Measured in Weeks, Then a Lean Startup is Going to Eat Your Lunch

Learn more about transforming people, process and culture with the Real Agility Program

Title inspired by Michael James…see below.

One of the most powerful assumptions built in to Agile methods is that we learn by doing — that our learning, our planning, our problem-solving, and ability to mitigate risk is enhanced when planning is performed inline with active development and in the context of deliberate experimentation.  Scrum, for example, is based on empirical process control theory which means that we make decisions based on what is known.

One of the most common pitfalls we see among organizations trying to “adopt” Agile is excessive pre-planning — their assumption being that we can decide by planning, learn by planning, or mitigate risk by planning.  This sometimes manifests as an anti-pattern that people call “Sprint Zero” — a signal that an organization misunderstands Agile methods fundamentally.  More importantly, a signal that the organization may incorrectly perceive Software Engineering — or any team-based work — as predictable and repetitive rather than the complex, creative endeavor that it is.

If your organization injects a “Sprint Zero” or a planning phase (that is measured in weeks rather than days or hours) ahead of the creation/development of real product, then these two posts are of interest to you:


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: The Cost of Turnover on an Agile Team

Learn more about transforming people, process and culture with the Real Agility Program

Great article by Mike Griffiths: http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Question: Product Owner and Technical Debt

Learn more about transforming people, process and culture with the Real Agility Program

Question from Meredith:

As a product owner, what are the best ways to record technical debt and what are some approaches to prioritizing that work amid the continuous delivery of working software?

Answer:

Hi Meredith! This is an interesting question. I’ll start by answering the second part of your question first.  The two most common ways of handling technical debt, quality debt and legacy debt are:

  1. Fix as you go. The Scrum Team works on new PBIs every Sprint, but every time a PBI touches a technical, quality or legacy debt area, the team fixes “just enough” to make the PBI implementation have no debt.  This means that refactoring and the creation of automated tests (usually through TDD) are done on the parts of the product/system that have the problems.
  2. Allocate a percentage. In this scenario, the Scrum Team reduces its velocity (sometimes significantly) to allow for time to deal with the technical, quality and legacy issues. This reduction could be adjusted every Sprint, but is usually consistent for several Sprints in a row.

In both approaches, the business is paying for the debt accumulated, and the cost includes an “interest” fee.  In other words, the sooner you fix technical, quality and legacy debt, the less it costs.  This approach to thinking about your product/system is essential for long-term sustainability.  One organization I worked with took three years working on their system to clean it up without being able to add any new features!  Don’t let your system get to that point.

Now to the first part of your question…

As a Product Owner, you shouldn’t really be making decisions about this cleanup work. Your authority is limited to the Product Backlog which should not include technical items. The only grey area here is with defects which may be hard to classify as either fully business or fully technical. But technical design, duplication of code, technical defects, and legacy code all are under the full authority of the Scrum Development Team. Practically, this means that every Sprint the team has the authority to choose however few PBIs they feel they can take while considering the technical state of the product/system.  We trust and respect the team to make wise decisions.

Therefore, your main job as a Product Owner is to provide the team with as much information as possible about the business consequences of the work they are doing.  With strong communication and collaboration about this aspect of their work, the technical members of your team can make good trade-off decisions, and balance the need for new features with the need to clean up previous compromises in quality.

A final note: in order for this to work well, it is critical that the team not be pushed to further sacrifice quality and that they are given the support to learn the techniques and skills to create debt-free code.  (You might consider sending someone to our CSD training to learn these techniques and skills.)

Using these techniques, I have been able to help teams get very close to defect-free software deliveries (defect rates of 1 or 2 in production per year!)

Let me know in the comments if you would like any further clarification.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: It’s Time to Kill Performance Reviews

Learn more about transforming people, process and culture with the Real Agility Program

For many years, folks in the Agile community have been recommending that performance reviews be eliminated from the corporate world.  In 2005 while coaching at Capital One, I remember many discussions on the awfulness of performance reviews.  This was really my first understanding of the depth of culture change required to be Agile.

Now, this concept of eliminating performance reviews is gaining traction outside the Agile environment.  Here is a great LinkedIn Pulse post by Liz Ryan in which she explains in depth about killing performance reviews.

From her article:

A little voice in the back of my brain nagged at me: “Despite your efforts to make them more compassionate and less uncomfortable for everyone, performance reviews are stupid from the get-go, Liz!

“How does one human being get to evaluate another one, when their personalities and perspectives may be radically different?

Consider using other techniques to help with improvement efforts among your staff.  Lean has Kaizen.  Agile has Retrospectives.

Real Agility means that learning is inherent in the culture of an organization.  Performance reviews establish extrinsic motivators for learning… and all the research points to the idea that learning is much more powerful when it is intrinsically motivated.

Consider some other tools that might help your team to work more effectively, while maintaining intrinsic motivation:

Finally, consider that, at least in Scrum, the concept of a self-organizing, self-managing team makes it very difficult to do performance reviews.  It is hard to apportion “blame” or “praise” to individuals.  Each team member is dynamically deciding what to do based on the needs of the team, their own skills, and their interest.  Team members are often collaborating to solve problems and get work done.  Traditional roles with complex RACI definitions are melted away.  Performance reviews are very difficult under these circumstances.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Daily Goal

Learn more about transforming people, process and culture with the Real Agility Program

When my Scrum team first proposed trying mobbing I wasn’t sure what to expect. No one on the team (including myself) was an expert. I reserved judgment and watched a few sprints. I stayed silent when the same team decided to skip the tasking out portion of planning and simply pulled in enough stories to fulfill their Sprint goal.

After a couple of sprints it became obvious that there were a number of pros; the team was engaged and aligned. They responded as a consistent, unified voice at Sprint Review and Retro. Planning went a lot faster as the team no longer wrote out all their tasks and didn’t have to copy all of them into Jira.

In particular, the Daily Standup’s usual agenda of “what did you do yesterday? what are you doing today? what are you doing tomorrow?” became redundant. And this had me thinking; ‘maybe the team didn’t need a stand up anymore? What’s the point?”

Then, one of the team members introduced me to the concept of the daily goal and I watched as he walked the team thru it. I thought this made a lot of sense and so did the team. We kept up the practice. Some days the team would forget about it or be too tired to bother. I noticed on those days the team wouldn’t be as clear on what they were working on or how to align on a particular challenge. I also noticed that the Stand Up the next day would be more fragmented and meander a bit. They would forget to communicate to one another and look at me as their Scrum Master expectedly, wanting me to drive it.

I started to coach the team back to their daily goal practice and reminded them this Stand Up was for them to align on the work ahead for the day. This became more important as the team divided up into mini mobs or pairs and were no longer one big mob.

I find the Daily Goal useful for a number of reasons. Instead of tasking out the work a week in advance, they decide how to approach the work on a daily basis that takes into account any day to day changes that have happened. Planning goes a lot faster now that we’re not tasking out all the work in advance. The team stays focused on a daily basis as opposed to at just Planning. They write their daily goal on their Scrum Board making it visible to anyone on the floor what their focus is for the day. Even better, the daily stand up as renewed purpose and the dialogue is more interactive.

Here are some examples of our Daily Goals:

  • Refactor Story 1
  • Coordinate with outside team members to align on test strategy
  • Complete happy path for Story 3
  • And sometimes it is as simple as “Complete story 4”

I hope to continue the practice and frankly, it’s fun! Achieving short time goals is motivating and brings a sense of accomplishment. I highly recommend it. Let me know your thoughts and if you’re trying this technique let me know how it’s working out for your team.

[EDITOR’S NOTE: Alexandra Dragon is a first-time contributor to Agile Advice – please welcome her in the comments.  And let us know if you are interested in contributing.]


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Daily Scrum

Learn more about transforming people, process and culture with the Real Agility Program

On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What Do Strong Companies Hire For – Skills, or “Something Else?”

Learn more about transforming people, process and culture with the Real Agility Program

Perhaps you’ve experienced this…You go all revved up to a job interview with your beautiful resume in hand outlining all your accomplishments, believing you have all the right training, skills and experience…but you’re not chosen for the position. You cannot understand why.

Advertising guru and author, Simon Sinek, explains: “Weak companies hire the right experience to do the job. Strong companies hire the right person to join their team.”

Teamwork is becoming the hallmark of most successful businesses and organizations. We have entered an age where cooperation and working together is a vital necessity. No longer is the individual star performer going to do it for an organization. That’s not enough. Everyone needs to have the same vision, the same values, the same feeling of being valued. The demands on companies is just too great for one or two individuals to lead the way. Everyone must be a leader.

How can one show a potential employer that you are a team player? That you have great consultative and cooperative skills? That you’re willing to learn from everyone around you? Is this something that can be reflected in your personality?

“A recent international study surveyed more than 500 business leaders and asked them what sets great employees apart. The researchers wanted to know why some people are more successful than others at work, and the answers were surprising; leaders chose “personality” as the leading reason. Notably, 78% of leaders said personality sets great employees apart, more than cultural fit (53%) and even an employee’s skills (39%).” http://www.linkedin.com/pulse/do-you-have-right-personality-successful-dr-travis-bradberry

Forbes Magazine has published online articles about the hiring process which are fairly old-school, even wishy-washy. Writers talk about knowing the clear skill-sets a company is looking for, and having a detailed scorecard that defines the performance objectives for the position. They also discuss qualities of behaviour, but do not define behaviour in any specific way. Their expertise falls short in looking at personality, team-building qualities, and desire to learn, change and adapt.

Agile is the leading team-oriented methodology being adopted by the best and the brightest organizations in the world, such as Google and Apple. Agile teaches its participants to reflect, act and learn.

This is a kind of life-agility that’s needed in every realm we function in, whether as spouses, parents, employees, or members of our communities.

What do you hire for?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

9 Agile Estimation Techniques

Learn more about transforming people, process and culture with the Real Agility Program

Many people have used a variation of Planning Poker to do Agile estimation.  Here is a reference of 9 different Agile estimation techniques for different circumstances.  I have seen all of these techniques work in practice, except one.  Try a new one each Sprint!

Planning Poker

Participants use specially-numbered playing cards to vote for an estimate of an item.  Voting repeats with discussion until all votes are unanimous.  There are lots of minor variations on Planning Poker.  Good technique to estimate a very small number of items (2 to 10).

The Bucket System

Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”.  The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase.  The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).

Big/Uncertain/Small

For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small.  The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.

TFB / NFC / 1 (Sprint)

This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint.  The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less).  I learned this one recently from someone in one of my CSPO classes.

Dot Voting

Dot voting is usually considered a decision-making tool, not an Agile estimation technique.  However, for estimating small numbers of items, dot voting can be a super-simple and effective technique.  Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.

T-Shirt Sizes

Items are categorized into t-shirt sizes: XS, S, M, L, XL.  The sizes can, if needed, be given numerical values after the estimation is done.  This is a very informal technique, and can be used quickly with a large number of items.  Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.  There is a brief description of T-Shirt Sizes here.

Affinity Mapping

Items are grouped by similarity – where similarity is some dimension that needs to be estimated.  This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range).  The groupings are then associated with numerical estimates if desired.

Ordering Protocol

Items are placed in a random order on a scale labeled simply “low” to “high”.  Each person participating takes turns making a “move”.  A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing.  If everyone passes, the ordering is done.  The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.

Divide until Maximum Size or Less

The group decides on a maximum size for items (e.g. 1 person-day of effort).  Each item is discussed to determine if it is already that size or less.  If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items.  This continues until all items are in the allowed size range.

Principles of Agile Estimation

Agile estimation techniques are collaborative.  All appropriate people are included in the process.  For example the whole Scrum team participates in estimating effort of Product Backlog Items.  Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.

Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy.  We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.

Most Agile estimation techniques use relative units.  This means that we don’t try to estimate dollars or days directly.  Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other.  This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).

Check out my recent “Agile Planning in a Nutshell” article.

What Other Agile Estimation Methods Are There?  Please let me know in the comments and feel free to include a link!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Agile in the Classroom

Learn more about transforming people, process and culture with the Real Agility Program

If you are a long-time reader of Agile Advice, you know I take interest in Agile methods used in non-software environments.  My buddy Mike Caspar has another great story about the use of Agile in the classroom, and in particular, how he has had an impact as a coach.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail