Posts tagged Agile

Value AND Velocity!

November 13, 2009 · Filed under Point2 - Process and People · Tagged , , , ,

In last week’s post I talked about how a stakeholder can use Value Points as a useful metric, and how to assign Value Points to epics.  Value Points are good for determining whether the team is working on the right projects but they don’t paint the entire picture.  This is where Velocity points come in.

At Point2, we estimate story sizes based on relative complexity.  The simplest thing we can do is a 1, something about twice as difficult a 2, and so on.  Some people prefer time estimates, either method of sizing stories is fine here.

Once you have both Value and Size estimates for your stories, you can plot them on a scatter plot.  Here I plotted story size on the X axis, and Value on the Y axis.  Small size, high value stories are in the upper left quadrant, low value, large size stories are in the lower right.  In this example, I would probably get the team to do all but 3 of these stories, those being the ones with size 5, value 2 and 3, and size 3, value 1.

scatterplot

The interaction between value and size is an excellent way to make sure your team is delivering the right product.  High value, low complexity stories are great for delivering some quick value, possibly as a means of generating the capital to tackle the larger projects.  Low value, high complexity stories might be best left on the shelf, or alternate means of solving the problem sought.

By: Tefon Obchansky

Leave a comment »

Value as an Agile Metric

November 5, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , ,

At Agile 2009 I attended Brandon Carlson’s talk entitled “Value or Velocity?“.  Velocity is often thought of as a measure of speed or productivity, but if a team can deliver x story points’ worth of the wrong product, and another team can deliver the same number of story points’ worth of an amazing product that everyone wants, but the two teams are said to have been equally productive based solely on their Velocity numbers.

In other words, getting more done is meaningless unless you know you’re getting the right things done.  To make sure you’re doing the right things, Brandon suggested assigning value points to epics.

The simplest method is Value Poker, kind of like Planning Poker.  The Product Owner assigns a value to each epic relative to other epics in the sprint backlog, with the smallest amount of value being a “1″, just like the story that requires the smallest amount of effort is a “1″ in Planning Poker.

Another, probably more accurate method is Attribute-Driven value assignment.  In this case, all product owners and stakeholders meet and assign values to epics together.  Each stakeholder will know the most about one or a small handful of attributes.  Some possible attributes include: market differentiation, strategic alignment, usability, system stability, sales commitment.  Draw up a chart with each attribute as a column, and each epic as a row.  The stakeholders for each attribute assign a value of 0-3 in each row for how valuable the epic is for that attribute.  Total up all the values for a row and then you have numbers you can sort on, and that can become your prioritized list,

To a stakeholder it is much more meaningful to hear “this month the team delivered 31 value points” as opposed to “this month the team delivered 31 story points”, because at the end of the day it’s delivered value that customers pay for, not complexity of stories.

By: Tefon Obchansky

Comments (3) »

Turning the Daily Scrum Upside Down

October 30, 2009 · Filed under Point2 - Process and People · Tagged ,

At the start of the last Sprint my team decided to move our Daily Scrum from 8:30 in the morning to 4:45 in the afternoon. Typically these meetings are done first thing in the morning, and for the last eighteen months that’s the way my team has operated. The change was not made because our morning stand-ups weren’t working, but after a little bit of conversation and observations over the last few months we thought we could make them better.

The workday for most Point2 developers starts at around 8 am, and wraps up at 5 pm. Since I’ve been a Team Lead I’ve held all of my teams’ stand-ups at 8:30. The idea was that it gave people a reasonable amount of time to check their email, get their coffee, and take care of whatever else they needed to prior to diving into the day’s work. Below is some of the things that we thought weren’t working as well as they could.

  • The previous day’s work was anywhere between 11 and 20 hours in the past, and no longer fresh in the developers mind.
  • We were seeing an awkward period of time in the morning between 8 am and 9am where developers were unsure what they should be working on. Do the pairs from the previous day get back together for 45 minutes?
  • Stand-ups would often go over the 15 minute time-box since the team was sometimes “too thorough” in their contributions.
  • There were four other teams having their Daily Scrums more-or-less around the same time in the morning, making it difficult for some representatives (systems, technical support) to attend all of the ones that were relevant to them.

So it has been a week since we began the experiment and during today’s Sprint Retrospective, this is what the team has observed.

  • The contributions made by each of the developers seems very thorough, with them no longer forgetting to mention something of importance. I personally think that the quality of the contributions have increased as well. All week phrases like, “I forget what my pair and I did in the morning, but….” were not heard.
  • As the developers start to roll into the office in the morning at around 8 o’clock, they already know what they are going to be working on since we setup our plan the previous day, including who they are going to pair with. Once they finish checking their email and grabbing their coffees they can get started on their day’s work. That awkward 45 minutes seems to have been eliminated.
  • Since we have some team members that need to be out of the office at 5 pm our stand-ups now have a hard time-box. People have obligations outside of the office and will make an effort to ensure their contributions are on point and efficient.
  • Our stand-up no longer coincides with any other teams’ so anyone who needs to attend can do so.

We understand that there are some scenarios we didn’t encounter that will take some creative thinking to overcome. Since we are devising our plan the day before, a developer calling in sick, or a production issue popping up overnight will throw a wrench into our plan. We agreed that these scenarios are not a regular occurrence and can be dealt with on a one-off basis.

As a team we have decided to continue our experiment during our next Sprint which kicks off on Monday. Despite all of the positive things we have seen so far everyone still feels that one week isn’t quite enough time to fully evaluate the modification. However one thing is for sure – we are all comfortable in making changes to our processes when something isn’t working, or just needs to get better.  Being agile has allowed us to flip an entire process upside down without second guessing ourselves.  We’re all out to make the best team we can, and are not afraid to make some course corrections along the way.

By Hemant J. Naidu

Leave a comment »

Coping with Change

October 23, 2009 · Filed under Point2 - Process and People · Tagged , , ,

While attending Declan Whelan’s session Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team at Agile 2009, he mentioned the Change Process Model introduced by family therapist Virginia Satir. Declan only touched on Satir’s model, and I found myself wanting to know more after I left. With Point2 going through a high degree of change in the last two years, I was very curious as to how the Satir Process Model fit in.

The Satir Process Model was initially introduced to help families deal with change, but coincidentally enough it was also used at an organizational level. It’s no secret that businesses have to change in order to stay competitive. However problems can arise as those changes are introduced, and what Satir’s model helps us understand is the natural stages encountered along the way. There are five stages.

Late Status Quo

  • The subject group is at a familiar place.
  • The group has a strong sense of identity, and are comfortable with each other.
  • Behaviour of individual group members can be predicted.

Resistance

  • Something foreign is introduced to the group which requires some sort of response.
  • The change is usually introduced by a small minority.
  • The rest of the group sees this as a threat to how things work, and fear losing their sense of familiarity.
  • The group will generally try to undermine the change, or avoid it completely.

Chaos

  • The group fully plunges into the change.
  • Relationships may change.
  • The group may no longer behave as they used to.
  • The group will lose their sense of belonging causing them to become anxious and vulnerable.
  • In this stage the performance and productivity of the group take a sky-dive.

Integration

  • Something clicks and the group starts to embrace the foreign element. They see ways to use it in a positive way.
  • The group begins to form new relationships, and a new sense of familiarity starts to emerge.
  • Performance and productivity starts to climb.
  • The group starts to experience genuine excitement.

New Status Quo

  • The group now levels off into a new comfort zone with new relationships, and have a sense of stability again.
  • Performance and productivity are now at a higher level than the Late Status Quo stage.
  • There is an overall sense of accomplishment.

The image below does an excellent job of illustrating the model.

Being aware of the stages of the Satir Process Model, and looking back at some of the changes Point2 has underwent, I can definitely see this model’s relevance. A good example would be a recent shift from product-centric teams to feature teams. Up until this point Point2 has always had each team focus on one product (or suite of products), but this approach made it difficult to ensure that the highest priority work items for the company were always being worked on.

Feature teams seemed to be the way other companies were dealing with this problem so the change was introduced. Sure enough there was resistance (including from myself), performance and productivity were hit, and the teams could no longer function as they once used to. But the teams did not give up, and  continue to push through their uncertainties. I believe we are still in the change process, but have recently started to fully understand and embrace the benefits of feature teams as the Integration stage implies. I don’t think it will be long before we reach that new status quo.

Understanding the Satir Process Model has given me a new perspective on change, and I look forward to seeing how Point2 copes with it in the future. I think it’s a great exercise, and recommend looking back at changes your organization has gone through while identifying behaviour that was encountered at each stage. Having that awareness is only going to make change that much easier in the future.

For an excellent post check out Steven M. Smith’s The Satir Change Model.

By Hemant J. Naidu

Leave a comment »

10 Temptations of an Agile Coach

October 9, 2009 · Filed under Point2 - Process and People · Tagged , , , ,

When you are in a position of leadership on an Agile team, there is no shortage of mistakes that you can make. Some of these mistakes may be trivial, but there are behaviours that can really limit the progress and efficiency of those you are supposed to be leading. While attending Agile 2009 in August, Stevie Borne gave a quick talk on what she felt were the top 10 Temptations of an Agile Coach. Whether or not you are in a coaching role, being aware of these temptations will help you identify them, and hopefully get them dealt with early.

1) Meddling
- Interfering with the team’s activities when you shouldn’t.
ex) technical work, updating story board, writing stories, creating acceptance criteria, etc.

Consequences
- Takes away from team ownership.

Tips
- Allow team to make mistakes.
- Make suggestions, but let the team experiment.

2) Impatience
- Unrealistic progress expectations, and pushing the team to go faster than they can.

Consequences
- The team becomes discouraged.
- The coach may burn out.
- End up spending unnecessary time and resources.

Tips
- Remember that change takes time.
- Find a coaching mentor to help with these situations.

3) Mastery
- You have all the answers, so you freely give them out.

Consequences
- The team fails to problem solve.
- The team become afraid to fail.
- It becomes your process, not theirs.

Tips
- Ask the team how they would handle it.
- Provide ways for them to solve problem, but let them choose what works best for the team. (guide through process of discovery)

4) Changeful
- New idea every iteration giving the impression of constant change for no good reason.

Consequences
- Team loses the chance to get the feel for new techniques.
- Become too focused on the how, not the why.

Tips
- Let the team try changes for at least 2 iterations.
- Make sure there is a good reason for the change, and make sure that it is well communicated.

5) Inflexibility
- Believe there is only one way to do things.  Worked good on one team, so it will work well on this one.
- Dogmatism.

Consequences
- Team loses sight of the value behind the practice.
- The team becomes alienated from you.
- The team allows the process to replace their own thinking.

Tips
- Learn new techniques to accomplish the same goals.
- Focus on principles, rather than practices.

6) Control
- Take control of the team through work assignment.  Often occurs when team faces delivery pressure.
- Injected work items.
- You start speaking for your team.

Consequences
- The team is no longer empowered.
- The team team loses respect for you as coach.

Tips
- Force yourself to step back and re-engage the team.  Give control back to them.

7) Utopia
- Preach that Agile will solve all problems. It’s the only way to work, and everything will go as planned.

Consequences
- The team loses faith in Agile principles.
- The team feels as though they have failed.
- The team is unprepared for potential disaster.

Tips
- Understand that discomfort during change is normal.  Admit it and learn to be OK with it.

8)  Love
- You want everybody to like you.
- Can’t take negative feedback.
- Avoid being bad cop.

Consequences
- Your feelings end up get hurt.
- The team stops being honest with you.

Tips
- Need to develop a thick skin.
- Stay objective, and only mention the facts.

9) Fuzziness
- Problems are talked about in vague terms with no path towards a resolution. ex) “we have so many meetings.”

Consequences
- Issues go unresolved and team becomes frustrated.
- The team grows apart.

Tips
- Ask the team questions. Use the 5 Why’s to find out what the real problems are.
- Name the issue and create an approach to attempt to resolve it.

10) Avoidance
- Avoid failure – unwilling to try new techniques.
- Avoid conflict – unwilling to challenge the team when things go awry.

Consequences
- Your team misses valuable growth opportunities.
- You miss coaching growth opportunities.

Tips
- Understand that occasional failure is OK.
- Find a coaching mentor and ask for help.

By Hemant J. Naidu

Comments (2) »

What happened to building race cars?

October 5, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , , , , , ,

When my older brother was a young man his fantasy was to be a part of a great team building cutting edge race cars. His passion led him to spend countless hours on his own figuring out how an internal combustion engine works, how well-tuned suspension helps keep power to the ground, and why one transmission was better than another. He got his foot in the door at the local garage and began his career as a mechanic. Today he is a very successful, respected and knowledgeable mechanic at a different local garage. I am very proud of him and the skills he has acquired over the years. But what happened to building race cars?

At his garage my brother had all the tools he needed plus skilled co-workers.  What stopped him from building his race car?  Whenever my brother wanted to work on something new, innovative, and generally cool he would have to wait until after work hours or the weekend.  Young and energetic he would complete his work day and dive into his own pursuits.  Sometimes he was even able to get co-workers to stay with him and try something he could not do alone.  This lasted for a while but as time went on he could not afford to invest the hours his creative mind was asking of him.  At the end of the day he would be exhausted and ill-suited to pour creative energy into his projects.

In the agile software development environment I currently work in I am surrounded by seasoned professionals, inexperienced raw talent, and everything in-between.  I am proud to be a part of a company that values professional development time as discussed in Hemant Naidu’s post, A Vivid Imagination Isn’t Just for Kids.  In doing this we acknowledge how important creativity and innovation is to the growth and success of our company.

In an effort to provide momentum to the professional development time the development leads have asked our developers to get together with no manager participation.  They have been tasked with using their professional development time to work together on the major hurdles affecting development across all teams.  It is our hope that leaders will rise, tribes will form, and developers will learn to work together on their own initiatives.  As a developer, expect from us the creative freedom to try, and from yourself the courage to fail.

By Logan Peters

Leave a comment »

Six impossible things before breakfast

September 30, 2009 · Filed under Point2 - Process and People · Tagged , , , ,

“Alice laughed: “There’s no use trying,” she said; “one can’t believe impossible things.”

“I daresay you haven’t had much practice,” said the Queen. “When I was younger, I always did it for half an hour a day. Why, sometimes I’ve believed as many as six impossible things before breakfast.”

Alice in Wonderland.

Creativity is a cornerstone of software development. Believe it or not, this is something one can exercise. A great way to train the creative part of your brain (right hemisphere) is to daydream or think about impossible things.

Why don’t you try it and follow the Queen’s advice ?

Suggestion:

Make this exercise part of your daily stand up when working on an Agile team. Ask your team members to come up with an impossible thing each. You’ll see how much fun this can be. Make sure they think about it before the stand up starts.

You can also do this exercise at home with your partner or kids. If you do this on a regular basis you will see your creative side improving.

We came across this idea in Tony Buzan’s book “Head First” and practiced for a couple of months. It can actually be challenging to come up with new impossible things every day.

By Barbara Mayerhofer and Marcos Tarruella

Comments (3) »

How Scrum Saved My Wedding

September 18, 2009 · Filed under Point2 - Process and People · Tagged , , , , ,

So what does a couple do when they are getting married in less than two weeks, and there is a pile of things to get done for the wedding? Well, when the groom-to-be is me, the obvious answer is that they organize the work using Scrum. I had floated the idea to my fiance a little while ago, and she wanted nothing to do with it. In her mind she felt that a list on our whiteboard would be just fine.

When we found ourselves a mere two weeks from the big day, I once again asked, “are you ready to do Scrum yet?” She reluctantly agreed, tweeting her displeasure for the world to see and we got underway. We knew there was a pretty big list of things to do so we started off with a Blitz Planning session.

I grabbed a stack of sticky-notes and we started to blurt out tasks that needed to be completed if this wedding was going to fly. As the tasks were identified I jotted them down onto the sticky-notes. Once we felt that we had a fairly comprehensive list, we took a few minutes to give each story a complexity value. A value of 1 was fairly trivial such as “pick up the wedding rings from the goldsmith”, while a 5 was reserved for things such as, “write our wedding vows.” We stuck with the Fibonacci numbers to allow for uncertainty in the larger tasks.

Since we had approximately two weeks before the wedding it made sense for us to have two, one week Sprints. With a table covered in pink sticky-notes, we moved each of the stories into one of two piles representing each Sprint. Now we were able to do a more fine-grained planning of each Sprint.

We knew that the more complex stories had higher risk associated with them so we made sure to start those as early as we could. We did however remain mindful to not overload Sprint 1 with only the large stories. There were some stories that needed to be done on certain days, and some that had dependencies on other teams which required some clever shuffling.

It didn’t take very long before we had our Scrum board organized into two Sprints. We split the board into columns representing each day allowing us to put the story cards onto the day we intended to complete them. This gave us a really good visual representation of the work ahead. This layout is actually very similar to the Scrum board my team at Point2 uses. Having a visual representation of when stories are scheduled to start and expected to finish is a great tool for the team, as well as stakeholders to get a sense of how well the Sprint is going.

We’re about halfway into Sprint 1 and things are going as I was expecting. Stories are being burnt up on a daily basis, while some of the more complex ones are taking longer than we had initially estimated (sanding and re-staining the kitchen light fixture…..which needed to be done prior to our rehearsal dinner at our house). Some stories we had hoped to start on a certain day have not yet started, while some were completed early. We’ve also seen a couple of new stories injected into the Sprint requiring us to reshuffle the board.

Obviously the Scrum process at home can only be, “Scrum-like”, but as the Sprints progress I am seeing many of the same things that my Scrum team at Point2 experience from Sprint to Sprint. So maybe Scrum isn’t actually going to save my wedding since I don’t think it was ever in jeopardy, but I do think it was a great exercise to see how applying an Agile method in a completely non-technical area yielded many of the same results seen in the software development industry. If anything, applying Scrum to the wedding preparation was a useful tool in devising a plan, allowing us to visualize and execute that plan, and have a little fun along the way….geek-style.

By Hemant J. Naidu

Comments (2) »

Blitz Planning at Point2

September 8, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , ,

One session that I attended in Chicago at Agile 2009, and thoroughly enjoyed, was Alistair Cockburn’s Blitz Planning workshop.  First, Alistair is an engaging speaker and is full of great ideas.  Second, it was the last day of the conference and I was eager to start trying some of these new tricks, tips and techniques I’ve learned about all week at home at Point2.

Blitz Planning results in “getting the contents of everyone’s head into a common space” and is meant to be speedy.  In the 90-minute workshop we planned a non-technical workflow (the process of getting up in the morning and getting out the door), then we planned an information kiosk system start-to-finish, and identified the earliest we could do the initial rollout.

blitzplanning1

Ideas are recorded on index cards by all members of the team as they come to mind and are not subject to scrutiny by other team members.  As a team member writes on a card, they call out their idea to help avoid duplication, and to spark more ideas from other team members.  When the team feels the plan is near complete, the cards are laid out on a table in chronological order, the plan is checked for completeness and any dependencies are identified.  At this time cards may be torn up, and more cards may be written to fill the holes in the plan or re-work it to remove dependencies and shorten the critical path to allow early delivery.  Alistair introduced the concepts of the “technical walking skeleton” and the “business walking skeleton” which contain the bare minimum to make it work, and the bare minimum to provide business value, respectively.  Your earliest possible delivery consists of both the technical and the business walking skeletons.

Unlike the information kiosk example at the conference, the project we planned touches existing systems and contains many moving parts.  Instead of 20-30 minutes to design a system and discuss it, we took an afternoon to write the cards and discuss, and we have more discussions and card-shuffling sessions planned for the next few days.  So far it’s been an interesting exercise and I feel like we’ve identified several potential problems early.  I’ll keep you posted.

By: Tefon Obchansky

Comments (2) »

Top 10 Tips for an Agile Coach

September 3, 2009 · Filed under Point2 - Process and People, Point2 - Technical · Tagged , ,

While at the Agile 2009 conference last week I had the opportunity to attend a session by Rachel Davies and Liz Sedley outlining some great tips for an Agile coach. Their presentation was based on their upcoming book Agile Coaching. They were approaching the topic as though they were an external coach brought into a company just starting Agile, but there was definitely some good take-aways that could be applied in any situation. I will do my best to regurgitate their discussion in hopes that you can make use of them in your coaching endeavors.

10. Get Introduced

  • What are you trying to achieve, what is your expertise? Experience?
  • Explain what you expect from those you are coaching.

9. Agile is not a Religion

  • Try not to come out as a preacher – this will likely switch the team off.
  • You must first understand the team’s circumstances before fixing things.

8. Show Respect

  • Understand the team’s history.
  • Do not tell them they are doing things wrong.
  • Listen to them and find out how they started doing things the way they are.
  • Understand the factors that led to the circumstances they are working in.
  • Be mindful of your language – use names and not labels (refer to people individually)

7. Step Back to See the Big Picture

  • Do not get caught up in individual interactions.
  • Look at the “system” as a whole – the way people are acting is usually a reflection of the forces acting upon them.
  • Do not fix the people, fix the pressures that are acting on the people.

6. Ask Questions to Spark Ideas

  • Improve the team’s thinking so they can think for themselves.
  • Well raised questions challenge people – allow people to discover their own solutions.
  • When a team is struggling, ask them about it – how can you guys make things better?
  • Do not ask why, rephrase the questions.
  • Ask a “thinking” question.
    • How long have you been thinking about this?
    • How do you think this will help?
  • Use the Five Why’s (RCA)
    • Root cause analysis asking “why” five times.
    • Explain why you are asking why five times – tell them what you are doing.
  • Do not ask a question if you really want to tell the team something – you will lose the opportunity to ask it.

5. Take Time Out to Reflect

  • Do not react to everything right away – do not rush into an answer because you are the coach and feel it is expected.
  • Better to think about it and come up with a calm solution, than to panic and provide an answer you have not fully thought about.
  • Agile Retrospectives is a good time to go over these things.

4. Introduce the Elephant

  • If you notice an elephant in the room, casually mention what you see (maybe in a retro).
  • This hopefully will spark conversation – do not push the team into talking about it if they are not ready to.

3. Make Change as an Experiment

  • “Let’s try something for a short period of time and see if it makes things better.”
  • Enable them to evaluate the results and decide as a team whether to continue.
  • Getting the team used to small changes. It becomes easier to introduce larger changes later.

2. Go With the Energy of the Team

  • What is the best problem to tackle first?
  • The one the team wants to solve – it may not be the most important, but it will get the team going.
  • Give the team ownership, and get them going on devising a problem solving solution that will be pertinent in the future.

1. Have Courage in Your Convictions

  • Understand that you are introducing change, but people generally do not like changing.
  • Have faith in your own ability to help the team.
  • Be passionate about what you are trying to accomplish with the team, and be clear about what you are trying to accomplish.
  • Ensure that they do not feel like you are pushing too hard – do not push until they are ready.

By Hemant J. Naidu

Leave a comment »

« Previous entries
Next Page »