Martin Fowler's Take on Co-located vs. Remote

I haven't posted in a while, but this is a good blog post I thought needed sharing.

How do YOU increase your team's velocity?

I don't know about you, but making bigger estimates does NOT increase velocity.  What are some ways you've measurably increased your team's velocity without making bigger estimates?

The Impact of Agile Quantified

Turns out, Rally has been collecting some very useful data!  Have a look!

Don’t Take Daily Stand-ups for Granted

For the uninitiated, gathering every day for 15 minutes to discuss the goings-on of current work might seem a little redundant and useless.  All the same people say many of the same things over and over again.  But to the experienced, there’s a lot more to it than that.

As I've previously blogged, at my current engagement my team is limited to only two stand-ups per week.  These stand-ups are open to everyone on the team, yet only the same three or four people show up each time.  As a result, communication seems to flow like molasses rather than a swiftly moving mountain stream.   Still, what we have now is far better than the black hole that existed before.  We are still light years from where we COULD be, however.  That old adage “You don’t know what you've got until it’s gone” made me reflect on why daily stand ups are so important. 

Daily stand-ups bring the team together.

This is not just in the physical sense, but in a social sense as well.  It forces the team to connect rather than just code or test away at their desks.  When you’re at a stand-up, you LOOK at your peers.  You interact with them.  You acknowledge them as PEOPLE rather than just the titles they hold.  Of all the purposes of a stand-up, I think this is the most vital because it physically embodies teamwork at its most basic level by forcing us to accept that we work with other people.  This may seem very rudimentary, but you can throw a bunch of people together in a group, and they won’t start becoming a team until they can at first acknowledge one another.  Think on that for a moment.

Daily stand-ups foster communication.

This is a no-brainer since we share what we’re doing with the rest of the team.  Beyond this, however, is the discussion that can spark from the simple phrase “This is what I’m doing today…”  Often, what you’re doing affects the person standing next to you.  I don’t know about you, but I’m not one of those scrum masters who make us adhere to a strict script in our stand-ups.  I give the guidelines and let the team’s discussion blossom.  The stand-ups that diverge from the traditional what-I’m-doing scripts are usually the most productive.  The team sees dependencies.  They strategically plan their work.  They start troubleshooting impediments.  They plan extra meetings for topics needing more in-depth discussion.  These kinds of communications are hard to get started via an email chain or by one-off conversations between isolated teammates.  Face-to-face contact on a regular basis somehow gives the team permission to meet whenever they have a need.   

Daily stand-ups reveal impediments early and often.

When we talk about our impediments in our stand-ups, we are in a sense asking the team for help.  Of course, we’re keeping them aware of issues, but chances are likely that one of our teammates may have dealt with the same problem and can offer a solution.  If they can’t, then perhaps they know who can.

 In my experience, it is also incredibly difficult for the PM/Scrum Master to run down solutions for impediments if they have to do it one person at a time.  This takes too long and can be detrimental to the success of a project.  Letting everyone know at once cuts out the middle man – the PM/Scrum Master – and gives the team a better chance of solving problems as they arise.     

Daily stand-ups create accountability.

If we daily stand together as a team stating our goals and asking for help, then we become accountable to one another.  In those stand-ups we tell each other what we intend to accomplish.  We make a commitment to our teammates in that regard.  Pretty soon teammates learn they can trust one another if everyone meets their commitments.  If you don’t accomplish one day’s goals, then invariably someone at the team level will want to know why.  This sparks discussion and perhaps solutions are born from the temporary setback.  It is better for this to happen at the team level than at the executive level.  If you can’t meet your commitments at the team level, then what makes you think you can meet commitments beyond that?  Your team is depending on you, and you depend on your team.   When we meet our commitments to one another, we make our team stronger.  We establish trust. 

There are no guarantees that you’ll have open, trusting, communicating, or accountable teams just by having a daily stand-up.  However, you have a much better chance of getting there by meeting regularly. 

What are your experiences with daily stand-ups?  Do you find that the more frequent they are, the better?  

Traditional Project Management vs. Agile Project Management: Week 4

So in my current role of PM, I'm experiencing the NEED to babysit EVERYONE on this project far more than I have in the past as a Scrum Master.  Here are some examples:

• No one is sharing information even after I've requested it.  I have to pull it from them.  For instance, I had no idea that two of my "testers" were even available for my team.  I find myself digging for documents after I've asked people to share them, too.  
• Expectations are completely unclear.  For instance, I just learned that I - as in ME - need to put together a test plan.  For you traditional PMs out there this probably isn't new for you, but I've never done this before.  Why?  Because I had self-organizing, cross-functional teams that took it upon themselves to take care of this crucial tidbit.  Now I get the unsavory task of asking everyone to document what they're doing so far.  
• Communication seems incredibly stifled since we don't yet have daily stand-ups.  For instance, dates (such as whether or not we'll have to work over the 4th of July weekend) have been up the air for at least two weeks. AND dare I mention the tester availability thing again?    

What are some differences you've noticed and how did you manage them?  I'm feeling like a fish out of water in this more waterfall type of environment (yes. pun intended.)

Agile Metrics: Be careful what you ask for

Albert Einstein once said, "Not everything that can be counted counts, and not everything that counts can be counted."  Ain’t that the truth? 

When looking at agile projects, there are a few very obvious ways to track team progress.  You can look at sprint and release burndowns, velocity charts, cumulative flows, etc.  However, what the business needs to ask itself is what it really wants from agile metrics, and it needs to be prepared to get what it asks for.   

 

There are many examples in which companies have set certain metrics that gleaned disastrous results.  There is one example in particular that seems to resonate the most, though.  A company once set the metric that the developers that found the most defects during code reviews would get extra “incentives”.  You can imagine what happened.  These developers wrote bad code, found bad code, and then collected the incentives.  The phrase “I’m gonna code myself a minivan” has its origins in this example. 

We can all agree that this was NOT the company’s intention.  Not in the slightest.  Yet, the company got what it asked for, yes?  So the company needs to ask the hard hitting question as to what it wants to measure and what it will mean.  Here’s a breakdown as to which metrics are for team use and which are for business use.

Velocity

Measuring the velocity of a sprint should be a metric to help the team.  Why?  Because velocity is all about estimating, and the team needs to become great at estimating.  Once a team has a few sprints under their belt, they can better estimate for the business how long certain projects will take.   Why would it be a bad idea for the business to harp on this metric?  Because the team will worry about how much they get done (quantity) and not what they get done (quality/priorities).  

Burndowns (Sprint and Release)

Again, this is another metric for the team.  This helps them gauge how well their tasks are progressing in relation to overall remaining work.  I think this is for both the team and the business, but again the business must be careful how it uses this data.  Every team is different.  Some teams hit the ground running and deliver daily.  Other teams take a little while to get traction, but they still meet their goals and deliver on time.   If you must draw a line, then do so between Sprint Burndowns and Release Burndowns.  The Sprint burndowns are more for the team to help them adjust on a micro level.  Release Burndowns are for the company so it can adjust on a macro level.   Again, if the business focuses on this metric, the teams will worry more about quantity rather than quality.   

  

Cumulative Flow

This chart is a more visual way to show what the team has finished in comparison to what is still left to do.  This is valuable for the team, but on a macro level, this is very valuable for the business when looking at product dependencies and delivery dates.   

Value Delivered

This isn’t as obvious as the cold hard numbers you can collect from velocity or burndown charts.  This one is a bit more subjective since the business needs to rank stories based on business value.  However when implemented effectively, this metric can provide a ton of value for the business.  This metric promotes value, not quantity, and in the end, customers want value. 

Time to Customer

Another valuable metric for the business is measuring the time it takes to deliver a product to the customer.  If a business can track how long it takes teams to deliver value, then it can better predict product launches and business costs.  This could get out of hand if the business pushes getting as much done as possible in any given timeframe.  Quality can seriously take a hit if value isn’t also encouraged. 

These are just a few ways to measure work in an agile environment.  There are many more that deserve a lot more discussion.  In the meantime, what do you think is valuable and how would you use it to satisfy  business needs?

What is it like being married to an agile coach, anyway?

On 03/11/14 7:31 AM, Robert Neil wrote: 
-------------------- 

Do you do private agile training? I think being agile is very important when participating in projects that require difficult positions.I would like you to show me how to properly scrum my wife. As a coach would you actually assist, or just give verbal advice during the "meeting"? Thanks for your time, and consideration.

You are now one step closer to being a Companion from FireFly.
This looks good, I would hire you.

On 03/11/14 7:49 AM, Amy Neil wrote: 
-------------------- 
LOLOLOL 

Dear Mr. Neil, 

Yes, I'm available for ALL kinds of coaching. Let's meet to discuss. 

Best regards, 
Amy Neil 
Agile Coach extraordinaire. 



On 03/12/14 10:11 AM, Robert Neil wrote: 
-------------------- 

Excellent. Hope I can afford your extraordinary skill set. 

Some Thoughts on Scope Creep

According to wikipedia (and various other sources), scope creep is defined as follows: Scope creep (also called requirement creep and feature creep) in project management refers to uncontrolled changes or continuous growth in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful.  

In an agile project, however, sometimes uncontrolled changes can be a good thing.  The whole point of agile software development is to be "agile".  We need to be able to pivot based on market/customer demands/need.  Market needs and trends change regularly, so by doing smaller projects and then breaking those into smaller chunks (iterations), we are able to readjust to get the market/customer what they need/want. Faster. With less waste.  

While uncontrolled changes can be good things in an agile project, continuous growth cannot.  If we are continually growing our backlog, then when will our project be done?  If we continually grow the list of things we are currently working on, then how can we meet our iteration goals or commitments?  Backlog growth comes, but it should be managed for FUTURE releases/upgrades/enhancements.  If the stakeholders really want these extra additions, then expectations should be set and all risks/consequences need to be thoroughly communicated.

How do YOU control scope creep?  Sound off!  

Managers CAN Help Self-Managed Teams!

One of the tenets of agile is forming self-organizing teams.  This brings autonomy and ownership to the teams that helps promote the agile value that favors individuals and interactions over processes and tools.  If the very definition of a self-managing team is a self-organized, semi-autonomous small group of employees whose members determine, plan, and manage their own day-to-day activities and duties, then what is the role of the manager?  Many have argued that if we have self-managed teams, then we do not need managers.  However, there always needs to be management or else teams can decline into chaos.  

So how much value does a manager bring in a self-organizing environment?   Plenty.  This “external leader” walks the line and can manage the boundary between the team and the rest of the organization, for starters.  She can build relationships, gather and share information, empower the team, and facilitate group processes as well.  She can coach the team in agile best practices while also facilitate meetings and coordinate schedules.  In short, a good leader of self-managed teams tends to do all these things and more.

Managing the boundary between the team and the larger organization can be a very delicate dance for the leader of a self-managed team.  While managing that boundary, the leader needs to give direction to the team from higher levels in the organization and also report team progress/ status back to the higher levels.  The leader basically represents the team’s interests in this flow of communication.  This also means that the leader must manage accountability; she holds the team accountable to the goals it sets for itself and also takes responsibility when those goals are not met.  The buck stops with the leader, and a good leader will lead her team by example.  

Managing that boundary also requires you to build strong relationships both inside the team and out of it.  Again, this is an agile value and can only help the leader of a self-managed team.  Outside the team the leader needs to be both socially and politically aware of the organization she works for.   Knowing how to navigate corporate politics will make her an asset to team so she can gain traction for their project needs.  The leader will need to know how to gain external support for her team, and that means knowing the right people to contact when the need arises.  Within the self-managed team, the successful leader will have also built team trust.  Empowering the team by encouraging the make their own decisions and then delegating the authority to follow through on these decisions helps tremendously with trust. 

Another way a leader can provide value and help to a self-managed team is by gathering and sharing information.  In agile projects, we want collaboration and transparency.  By seeking information from managers, peers, and specialists, a good leader can use this information to help diagnose and remove impediments for the team.  This keeps the team’s momentum going forward rather than being interrupted.  It also keeps the rest of the organization informed, as noted earlier. 

That momentum can be kept going in a myriad of ways, and the leader of a self-managed team is the right person for the job!  Having knowledge of the team’s work practices definitely helps in this area, but the leader can help facilitate the ceremonies of an agile project (planning, retrospectives, schedules, etc.).  Getting the project started and keeping it going is something the team doesn't necessarily have the bandwidth to handle, so having a leader to keep things going and help the team respond to change benefits everyone.

Overall, having a leader on a self-managing team is not as oxymoronic as it sounds.  Whether it’s managing the boundary between the team and the organization or simply keeping things moving forward, the successful leader can help behind the scenes to keep the cogs of the well-oiled, self-organized team on track for success.  

How do two agile coaches organize and prioritize their work?

LIKE THIS!

Backlog Grooming

I was going over some backlog grooming ideas with one of our Product Owners recently, so I thought I’d share these ideas with everyone.  

When preparing for sprint planning sessions, please take a moment to make sure the top 20 stories in your project backlog are “shovel ready”.  What do I mean by this?  Shovel Ready means that the stories have advanced to a state that allows teammates to IMMEDIATELY start working on them.  Ideally, this should be done even before Release Planning, but that can’t always happen.  

Here’s how we get them shovel ready:

·        UAC in EVERY user story

o   The team needs to know what the Product Owner’s definition of done is.  Your definition of done is your user acceptance criteria.  Don’t leave this to sprint planning.  We tend to go down rabbit holes as to what DONE actually means.  Product Owners, it is your job to set this standard, and it is the team’s job to tell you whether or not your UAC is possible in the context of the story.  THAT’S what needs to be discussed during planning. 

·        Possible story breakdown

o   Evaluate your user stories so succinctly that you can foresee whether or not they need to be broken down into smaller stories.  If you think you can group certain data flows or business rule variations, then do that ahead of time.  If you are not sure how to break them down, check out Richard Lawrence's How To Split a User Story again .  If you’re still at a loss, then by all means bring it to the team. 

·        Prioritize the backlog

o   Have the most important things you want worked on AT THE TOP of the backlog.  Make sure the team knows this priority, and make sure this priority is reflected in the goals you set for the sprint. 

·        Story Language

o   Please try to write stories in the format of “As a <blank> I want <blank> so that I can <blank>”.  This helps us keep the end user in mind.  I understand technical stories come up, but we need to try to stick to this idea as much as possible.

o   Be very specific in the language of the story.  Make it reflect the end goal.

If you have any other ideas you’d like to share, let’s share them!  Let me know if you have questions, as well.  Each of you have your own awesome style of handling user stories, so I encourage you to learn from one another as well.  

How many types of Agile Retrospectives are there, anyway?

The other day I noticed that we were getting pretty stagnant with our sprint retrospectives.  I have been asking these questions: “What went well? What went less well? What areas improved from last sprint? What areas need improvement?”  Sometimes we get some good discussions going, but most of the time I have to prod my teammates for answers and feedback.  This prompted me to go in search of something new and better. 

I have 4 teams, so it is important for me to come up with good ideas that can be used across the board.  My teams are also spread across the United States and Canada, so activities in which ALL of us can participate is definitely limited.  Pickings were slim.

I found a nice wiki that listed out many different types of retrospectives.  I pulled the below table from there. I had NO IDEA there were so many, and there were quite a few listed that I'd never heard of before. You can go to the link to delve further into each type of retrospective if you like.  This was a good start for me to get some ideas.

Name	Summary	Use	Approx. Duration (mins)
6 Thinking Hats Retrospective	Uses De Bono's 6 Thinking Hats to investigate process improvement	General use, but also a good alternative to shuffling card type retrospectives	60
Pillars Of Agile Spiderweb Retrospective	A retrospective in which teams rated their abilities in each of the categories, displayed the different ratings on a spider graph, and then discussed the result.	To talk about what abilities are important to an Agile team and how your team rates against them	60
Appreciative Retrospective	Uses Appreciative Inquiry to identify what went so well. There is no blame or negativity, and builds on the Prime Directive, that everyone in the team did the best job they could possibly do.	To remind everyone what a good job their doing rather than focusing on negatives every time you run a retrospective.	60
Top 5	Participants choose top 5 issues and bring them along for group to discuss and resolve	Expose the most pressing issues in an initially anonymous manner and determine the most effective actions to resolve them	45
Plan of Action	A Retrospective Technique for short term actions from long term goals	Really good for forcing achievable actions from your retrospectives.	40
Start, Stop, Continue, More of, Less of Wheel	The facilitator captures team open-ended feedback using a wheel that encourages team members to assess an iteration or milestone using 5 categories. Allow some time following completing the “wheel” to discuss and agree on specific changes to implement	Obtain feedback on team process in order to learn what should be continued and what should be adjusted as the team moves forward. Is a fast way to conduct a “meta” process discussion.	10-25
Each One Meets All	The method ensures that each participant meets and interacts with every other participant.	When retrospective participants do not know each other well	Variable!
The Complexity Retrospective	Use various tools such as a complexity radar to discover and find out how to deal with the complexity in your project	Many projects go awry due to excessive complexity; use this plan to evaluate whether your team is approaching things in the simplest way that can work; especially when the deadlines begin to loom.	40-60
Force Field Analysis	A plan designed around the force field analysis technique	A retrospective for your whole company/department or to analyse a particular topic	60
Pomodoro Retrospective	Focused and time-constrained by using the Pomodoro technique	Useful for determining a single action to improve the work of a small team	25
Retrospective Surgery	A retrospective for retrospectives	To learn how to improve the effectiveness of your retrospectives	60+
Questions Retrospective	Iteration retrospective	To get different perspectives on the same events	60
Everyday Retrospective	Simple sprint retrospective	Basic / everyday retrospective plan	90 - 120
Four L's Retrospective	Liked – Learned – Lacked – Longed For	Iteration and project retrospectives as well as for retrospection of training and conference events.	90 - 120
Sailboat	What anchors slow the team down, what wind propels it forward?	Good for the "gather data" and "generate insights" portions of a retrospective	90 - 120
Weekly Retrospective Simple + delta	Review, Plus-Delta, Vote, Actions, Owners	A weekly retrospective for your project	60
Jeopardy Retrospective	Use the answers as base to get all the good things and bad things that happened	A different way to "gather data" and to get all different opinions on a subject	60
Bubble Up	An approach to scaling retrospectives by collecting outcomes across an Agile Release Train, Tribe or any multi team scenario.	Use for understanding challenges and opportunities across when scaling agile.	15-30

I’ve decided to try a few of these: Plan of Action, Start /Stop/ Continue/ More of/ Less Wheel, Retrospective Surgery, Four Ls Retrospective, and Bubble Up .  I also like the ideas listed in the Everyday Retrospective, but I’m not sure I can cram all of that into the 15 minutes I have allotted for each team scrum.  In any case, I’ll chronicle the results here over the next few weeks. 

I was most excited about Sailboat, because it was touted as being great for distributed teams.  I was excited until I went to the website and found that it is no longer available as a collaborative game.  However, there are many other tools on that website that I found useful.  For instance, I might do the “Actions for Retrospectives” game with my distributed teams.  You can check out all the fun at http://innovationgames.com/resources/instant-play-games/ .  I might try using the Sailboat, though, for co-located teams. 

If you have any retrospective ideas you’d like to share, please let me know!  I welcome your feedback!  

Recommended Agile Reading

From time to time, I will review and/or list books that I find helpful.  I don't have time to go into a full review while I'm on my lunch break, but right now I'm re-reading 
The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers), by Jonathan Rasmusson.  It's a great back-to-basics book for those of us who have been doing the agile thing for a while.  For those of us who are newer to the agile universe, it is a must have for your Agile Library.  It also has some great tips and tricks for all role types.  I highly recommend it.  You can get the Kindle Edition for less than $20 on Amazon right now.  

How to Give a GREAT Demo!

One of the major tenets of Agile is the Product Demo.  As we all know, agile encourages us to demo at the end of our sprints.  This is done for several reasons.  Not only does this keep us accountable to our customers, but it helps us to focus on forward thinking.  At many companies, it is highly likely that actual external customers will attend these demos, so it is of the utmost importance that we always put forth our very best. 

In our pursuit of excellence, here are a few things to keep in mind when prepping for a demo. I compiled this list with a few of my collegues, so I can't take all the credit.  Here goes.  

What to include in every demo deck

Frame the demo with PowerPoint and then broadcast it via a webinar.  Just about everyone has access to a phone and the internet, so use them.  You can bring in your external customers this way, while still catering to your internal customers.  That being said, always be cognizant of WHEN you have customers attending your demos.  Make sure you inform everyone just who is on the phone so that you’re on your best behavior. 

That’s great, you say.  But what should I include? 

Project Goal 

This is basically the goal of the project, our elevator pitch, our reason for being.  This needs to be repeated at every demo because our audience fluctuates. 

Customer Value

This is the reason the world needs our project.  Again, the overall customer value of the project needs to be repeated every demo.  However, sprint specific value can be spelled out in the goals we set for ourselves.  We should be able to answer questions like “What have we given to customers thus far”, “What are we delivering next”, and “What are our plans for future customer value?”  Additionally, customer value should be integral to every part of our demo.  When we show something live, we need introduce it in such a way that spells out WHY it is valuable to our internal and/or external customers.    

Sprint Goals

I think this is optional for demos that include external customers.  You don’t want to get TOO in the weeds because you want to keep your external customers engaged. 

These goals ultimately align with the overall project goal, but think of them as bite-sized pieces that we can deliver iteratively.  Sprint goals usually change every two weeks and are specific to the work to which we’ve committed.  These goals should manifest with customer value in mind.  Remember: customers are both internal and external. 

Project Status

This lets everyone attending the demo know the health of our project.  It should answer questions describing how we’re tracking to our road map deadline, how much work is left, and whether or not we are meeting our commitments.   We also need to comment on major milestones or epics: are they done, and if not, are they accounted for?  Finally, do our customers KNOW what we’re giving them?  Have we communicated TO THEM the way we’re going to change their world for the better? 

Live Demo 

Show everyone how awesome we are!  Get to it with live demos of transitions, versioning, provisioning, wireframes, slick UI, YOU NAME IT.  DO NOT merely insert slides stating what we did.  SHOW IT OFF!  If we have very little or nothing live to demo, then we need to show reports, matrices, RACIs, Visio diagrams, etc.  This is all in addition to anything live we can show.   Also, we shouldn’t demo any stories that are incomplete.  That’s just plain silliness.    

What to Expect Next

“What To Expect Next” is usually the Product Owner’s vision of things to come, tempered by the realism of the team as a whole.  While we haven’t had planning for the next sprint yet, we need to let our audience know what’s on the horizon for our project.  This gives them the opportunity to plan whether or not they need to attend or whether or not they can move forward with their own agenda (project dependencies, sales pipelines, roadmap planning, etc).   This also keeps us always looking forward.  Keep in mind that “what to expect next” can change based on feedback and market trends, and this is the very reason why we demo!  We need that feedback to make sure our customers are getting the value they’re asking for.

Things you need to do as a teammate

BE THERE

This means physically as well as mentally, even if you haven’t contributed much during the sprint.  Try to avoid being out of the office on demo days.  Being together lends credence to what we’re doing, and it also serves to bolster team morale. 

Participate

While not everyone can participate at every demo, make it a point to participate as much as possible. 

Make sure the demo is recorded

This is more for moderators/facilitators, but if you can, help remind them to push the “record” button.  Recorded demos help keep our executives and sales folks in the loop when they can’t make it to demos.  

Tips and Tricks

Announce wins

If we’ve done something great, then we need to shout it from the rooftops!  Find creative and exciting ways to weave these wins into the demo deck. 

Demo Prep

This is a dress rehearsal, so to speak.  In prep we can iron out technology wrinkles, get a feel for presentation flow, and actually calm our nerves.  I like to do demo prep an hour or so before the demo.    

If we promise something in a previous demo, we need to deliver it in a subsequent demo.  If we don’t, then we need to explain why.

This is self-explanatory.

Have fun with images! 

Image searches on Google bring up loads of crazy things.  Create interest!  Incorporate some of these into our demos!  Of course, all things should be done in moderation and good taste.  Remember: external customers can and will see these demos!

So that’s it in a nutshell.  Be prepared and have fun!  What are some ways you give great demos?  Chime in!