Skip to content

Blogs

An Even Better Way to Use Puppet Modules in a Vagrant Project

I previously blogged about what I thought was a good way to tie librarian-puppet and vagrant together in a way that allowed one to use librarian puppet without dealing with rubygems on their system (which despite the excellent tooling can be a pain for non-rubyists).

Today I discovered there is a handy vagrant plugin for this and found that using it is a much better approach.

For the quick and dirty on how to use it:

Suffice to say, you should just use this instead.

Categories: Blogs

Tips for Improving Your Geographically Distributed Agile Team

Johanna Rothman - Tue, 06/17/2014 - 16:01

At the Better Software/Agile Development conference a couple of weeks ago, I gave a talk entitled At Least Five Tips for Improving Your Geographically Distributed Agile Team. (That link goes to the slideshare.)

If you look at Scott Ambler’s 2011 survey, you can see that his data matches my consulting experience. About half of all agile teams have at least one person not co-located. This is by management design.

We can say, “don’t do this,” but that’s not helpful to the distributed and dispersed teams. I would rather be helpful.

For example, in my talk, not the slideshare, I actually said, “Don’t do standups. Do handoffs.” If you are more than about 4 or 5 hours apart in timezones, standups make little sense. You are better off limiting WIP (with a kanban board) than using straight Scrum. Yes, use iterations if you like. You might like the focus of the timebox. But, consider using handoffs, not standups. Change your questions to statements—if that works for you. Change your deliverables to fit your needs.

One tip that created a ton of discussion was the one about keeping people together over time. Some managers are trying to be “efficient” about using team members, optimizing at the lowest possible level. They move people off and on teams, willy-nilly. (Groan.) I explained that agile is about finishing features, so their best bet was to optimize at the project level, or the project portfolio level. It didn’t matter if people weren’t fully utilized. People were best utilized when they asked, “How can I help move this feature across the board?” In a geographically distributed team, that is sometimes a difficult question to answer, especially if the testers are east of the developers.

I had stories, and we had audience participation, which is why the slides are sparse. I hope you enjoy the slideshare. If you have questions, please ask away in the comments. I will answer.

Categories: Blogs

CDE and Big Brother

Dear Junior
What can a sleazy soap opera teach us about coaching agile teams and their managers?
It was somewhat a surprise to me when I realise that the reality TV show Big Brother makes a good metaphor for explaining one of my favourite models for understanding self-organised teams: the CDE-model.
The Big Brother TV-show is a non-scripted soap opera where a bunch of people are locked up in a house together and followed by cameras day and night. The "thrill" of the show is how the people interact and react upon each other.
The CDE-model is a system-theoretic model to reason about how teams self-organise as a reaction on their surrounding. Of course these reactions are very non-linear and hard to predict.
What on earth have these two things in common?
Let us put ourselves in the shoes of the Big Brother producers. Say that the events in the locked house have become a little bit dull lately. The people locked up have settled for a pace of life where they all sustain without unnerving the others. Nice for them, but not thrilling TV. We need something to happen.
The problem for us is that Big Brother is non-scripted. We cannot direct Susan to "go and snug up Jonathan", even if we think it would be an interesting turn of events. We need to find other ways to change the behaviour inside the house without giving explicit directions.
So we decide to shake them up a bit by changing the conditions under they live. A rough partition can separate three types of conditions: containers, differences, and exchanges.
Containers
One type of conditions we can change are the containers.
We can lock the yard so that they are locked indoors. That will unsettle Bob who is used to take his morning strolls there. He might have to spend his mornings in the kitchen together with Alice, who has a terrible temper before getting her coffee. Or, we can open up an extra room, one that is a little bit hidden away, with very little insight - apart from the camera of course. Or, in the middle of the night we could push in an extra wall dividing the house into two parts; let us ensure that Tom and Lisa are locked up in one part, and Toms rival Jerry in the other part. Or, we could simply remove all doors. That could be fun.
All these are examples of changing the containers that contain the contestants - making the containers bigger, or smaller, or less connected, or more connected, or even dissected. 
Containers need not to be physical, there are other ways to divide a group. We can create a competition between two teams, then the teams become sociological containers. The teams can follow some obvious partitioning like city of birth or gender, or by some arbitrary dissection. 
The important part is that containers effect the patterns of interactions, so changing containers will change the behaviour.
Of course we could interpret "containers" literarily and put them all in a freight container. That is an idea.
Differences 
Another type of conditions we can change are differences and how they are resolved.
We can stir up events by introducing differences. For example, if we have an group of contestants with the same ethnicity we can send in a new contestant of a different ethnicity, for example sending in a white guy when there are only hispanics in the house. Or send in a professor of philosophy in a house with high-school drop-outs. You get the idea.
Sending in someone fair-haired when all are brown-haired will probably not make a lot of fuzz. In Big Brother, hair colour does not make a difference to how people treat each other - at least not in a way that make a significant change. We say that we only consider "significant differences". 
It differs from situation to situation what is a "significant difference" but in general the nuance of hair-colour is not one, whereas gender is - men and women are (sadly enough) treated differently. Same goes for ethnicity, sexual orientation and lots of other traits. All those are significant differences.
Introducing or enhancing differences are sure thing to induce change, but sometimes reducing differences can also unsettle the state of things.
Let us say we want to send in one person when there are four men and one women left in the house. Sending in a man would enhance differences from 4-1 to 5-1. Sending in a women would reduce gender difference to 4-2, but would probably be more interesting.
Apart from the differences as such, we have the issue about how these differences are resolved. 
One contestant might enjoy a particular kind of music, and preferably at high volume. Another contestant might not be so fond of that particular kind of music. However, they might be able to stand each other on a day-to-day basis. The difference is manageable, handling it is not difficult.
Now we can amplify the difficulty to manage differences, for example by introducing a large amount of liquor. Should either of them get drunk, or both, it will be harder to resolve the difference in taste of music, and we will probably see some interesting conflicts. 
Another difference is food preferences, one way to amplify the effect of this difference is to insist that everybody in the house agree on what should be served for dinner. Can be fun to see how Mark "must have meat" tackles Vegan-Lisa, even more interesting when he gets hungry. 
As differences and resolving differences are a major driver for interaction, obviously changing those differences will change behaviour.
Exchanges
Third and last of the conditions are the exchanges with the outside.
If we let the contestants interact with the outside things will happen. We might let each of them have a (filmed) phone-call with a friend. Or we can have a small room where one at a time is allowed to speak to the audience. Or we might take away that room. We could put up a big TV showing news from the outside. We could fake the news we show. Surely things will happen.
Exchange need not to be communication. We can change the way food is delivered to the house; instead of small deliveries every day we make one big delivery once a week. That will cause some interesting effects at the end of the week when someone has eaten all the goodies on day one. If we are diabolic we can give them slightly too little to eat. Surely things will happen.
As exchanges are the connection between the very limited system in the house, and the very large system on the outside, it is not surprising that how the inside and outside are connected will effect the behaviour on the inside.
CDE
Of course there are a multitude of ways to unsettle the status quo in the house. However considering containers, differences, and exchanges (CDE) gives a good start to think about what leverages we can pull to cause the people in the house to behave differently. Or phrased in system lingo: to make the system reconfigure itself in another configuration.
System theory teaches us that lots of systems are dynamic and non-linear. This means that it is very hard to predict the exact outcome of a change.
As producers of Big Brother we know this. When we nudge the system in the house, we know that something will happen, but we do not know exactly what. We can have a guess, but we do not know. So, we need to be at our toes to watch out if things go another direction, and take compensating actions - or actions we hope are compensating.
Well, obviously neither you nor I are producers of Big Brother. And most probably we will never be. But same ideas can be applied to think about agile software teams that have self-organised and when coaching them or their managers. However, that is a subject which is a letter of its own.
Yours
   Dan
PS To be honest, my description does not perfectly fit how CDE was described by Glenda Eoyang in her Ph D thesis. But I think I am truthful to the main idea.
PPS Glenda Eoyang’s thesis can be read in full at http://www.hsdinstitute.org/about-hsd/dr-glenda/glendaeoyang-dissertation.pdf. A briefer introduction can be found at http://wiki.hsdinstitute.org/cde.
PPPS I think first time I came across CDE was when Mike Cohn introduced it to me during is tour when he released Succeeding with Agile, a good book for a lot of reasons and which also includes an introduction to CDE.





Categories: Blogs

How Management Can Help Team Performance

Scrum Log Jeff Sutherland - Tue, 06/17/2014 - 08:45
Withdrawal of Team Autonomy During Concurrent Engineering
School of Business and Department of Systems and Computer Engineering, Carleton University, Ottawa, Ontario, Canada K1S 5B6,
School of Business and Department of Systems and Computer Engineering, Carleton University, Ottawa, Ontario, Canada K1S 5B6,Permalink: http://dx.doi.org/10.1287/mnsc.43.9.1275Published Online: September 1, 1997Page Range: 1275 - 1287AbstractTeam autonomy is an essential characteristic of cross-functional teams engaged in concurrent engineering. At the same time it is a characteristic that North American firms have considerable difficulty in successfully implementing. Delegating a good deal of decision making to teams is often counteracted by processes that during a new product program withdraw some of a team's autonomy or discretion. Data from 53 cross-functional product development teams in 14 firms indicated that withdrawing autonomy is negatively correlated with both task and process aspects of team performance. The determinants of withdrawing discretion include lack of a shared understanding of the development process, environmental change, and lack of managerial “buy-in” to team autonomy. Consequently, successful implementation of team autonomy, through mitigating withdrawal of discretion, requires a clear well-communicated model of the development process, a freezing of design revisions, and policies that encourage managers to support the team rather than interfere in its decision making.
Categories: Blogs

Certified ScrumMaster Workshop in Montreal—December 1-2

Notes from a Tool User - Mark Levison - Tue, 06/17/2014 - 00:28
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Montreal—December 1-2 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

New Content: Coordinating Multiple Release Trains in a Value Stream

Agile Product Owner - Mon, 06/16/2014 - 23:10

As SAFe and scaled lean-agile practices make their way across the chasm to the larger enterprise (see Geoffrey Moore’s Crossing the Chasm for the chasm metaphor), we are seeing rapid, and significant increases in the scope of application of the framework. In some cases, this is even a quite large initial scope, which includes multiple agile release trains from the start. For example, we’ve recently participated in SAFe rollouts that reach and teach 200-300 practitioners in the first launch, in one case with four trains launching simultaneously over the course of a little more than a week, (ahhhh, the value of the “courage of your convictions,” demonstrated in even the largest software enterprises.)

In turn, this brings increasing focus on the practices necessary to Coordinate multiple release trains in a value stream, including a new set of issues around content authority, full system integration, and releasing, which  will be a major focus of SAFe 3.0, as the figure below shows.

SAFe 3.0 Portfolio Image with Coordination Highlighted

SAFe 3.0 Portfolio image with coordination highlighted

In the meantime, we’ve developed much of the content for this new “Coordination” article, and we’ve included it here in Guidance, which replaces the prior guidance article on the same topic.However, as described in this article, when the value stream is too big for a single ART, then a new set of issues around content authority, full system integration, and releasing arise.

Comments welcome.

By the way, hope to see some of you at Agile 2014!

 

Categories: Blogs

Next SPC Certification in Boulder, Sep 9-12. SAFe 3.0!

Hi Folks,

I’ll be teaching the next certification in Boulder September 9-12. This is the first course I’ll be teaching based on SAFe 3.0, which will be released July 28. This should be a fun course; at least I’m excited about teaching from the new baseline! You can register here.

Hope to see you there.

–Dean

Categories: Blogs

5 Rules For Mastering JavaScript’s “this” – The eBook Version!

Derick Bailey - new ThoughtStream - Mon, 06/16/2014 - 19:55

I’ve had a number of requests for a better formatted, code-highlited, non-email version of my increasingly popular 5 Rules For Mastering JavaScript’s “this” email course in the last few weeks. To make this all happen, I decided to put it all together in to an eBook version, over on Leanpub.

About The eBook

Wondering why JavaScript’s “this” is pointing to that, when you thought it was pointing over there? Confused by the seemingly arbitrary value of “this” … if it even has a value?

You’re not alone.

JavaScript’s context variable is one of the most frustrating and confusing bits of important information that you need to understand. But don’t worry – the rules for managing “this” are easier to understand than most people think. It only takes a little knowledge, a few examples to work with, and a willingness to travel the path.

The name says it all: 5 Rules For Mastering JavaScript’s “this”. This book is split up in to multiple “days” – a short chapter each day, designed to guide you down the path of mastering “this”. 

Start The Journey

Head over to the Leanpub page for the book, and get started with the 5 day journey that will have you handling “this” like a pro!

     Related Stories 
Categories: Blogs

Robust Agile Requirements - Its about the Discussion

Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit).  However, not enough is written about the key ingredient of a robust requirements process.  Some will say that when you document the requirement, you are done with the requirements process.  I content, that this is just the beginning.  The real value of a requirements process is not just writing it down, but it is to begin the collaborative discussion. 
In an Agile world writing down a requirement begins the discussion between the business and engineering side.  Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins.  This discussion initiates the learning amongst the business and engineering side where the engineering side better understands the business value of the requirement and the business side better understands the technical options of the requirement.
It goes much deeper than this.  In the old world, there is a typically only a one or a very few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘throw over the wall’ to development.

I would suggest a much more robust approach starts with writing down the requirement but then the fleshing-out of the requirement occurs in a collaborative manner with the whole team.  This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement. 
From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team.  As an example, this could be in a grooming, refinement, agile release planning, or sprint planning event where the highest priority requirements are discussed and fleshed-out with the team’s input.  During this session, the collaborative discussion may focus on the following: 
  • Understanding why it is a high priority
  • Validating/updating the User Story is in Canonical Form (or defined form)
  • Understanding the business value and customer perspective
  • Considering technical details
  • Describing acceptance criteria
  • Identifying unknowns and risks (each should have an action to investigate and mitigate)
  • Identifying what is out of scope
  • Identifying dependencies
  • Decomposing epic to user stories or each user story to tasks
  • Providing sizing (e.g., story points, etc.)

As the collaborative discussion ensues, the requirement gains more clarity, where there is a team understanding of the work.  As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement.  At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue.  There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements.  Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it. 
Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach.  Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.
Categories: Blogs

The Next 7 Habits of Highly Effective Coaches: Habit 10 – Use What You Know

Portia Tung - Selfish Programming - Mon, 06/16/2014 - 11:00
Habit 10 – Use What You Know

Reading lots may make us feel cleverer, but it doesn’t necessarily improve our effectiveness. Knowledge through study without practical experience makes reading a hobby at best and, at worst, a waste of time. To get the most from our knowledge, we need to apply it.

Exercise: Personal Practice

Pick a tool you’d like to learn more about. Share it with a friend. Take turns applying the tool then reflect on what you’ve learned – about yourselves, about each other and figure out together how you can use the tool to solve a common problem.

For more information, see: The Johari Window – a tool that gives you a view on how you interact with other people around you.

About This Blog Entry

The Next 7 Habits of Highly Effective Coaches is part of a mini series inspired by the style of Paul Coelho‘s “Manual of the Warrior of Light“. You can find the first 7 habits here.

Categories: Blogs

Applying a Collaborative Discussion approach for building Robust Requirements

Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit).  However, not enough is written about the key ingredient of a robust requirements process.  Some will say that when you document the requirement, you are done with the requirements process.  I content, that this is just the beginning.  The real value of a requirements process is not just writing it down, but it is to begin the collaborative discussion. 
In an Agile world writing down a requirement begins the discussion between the business and engineering side.  Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins.  This discussion initiates the learning amongst the business and engineering side where the engineering side better understands the business value of the requirement and the business side better understands the technical options of the requirement.
It goes much deeper than this.  In the old world, there is a typically only a one or a very few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘throw over the wall’ to development. 


I would suggest a much more robust approach starts with writing down the requirement but then the fleshing-out of the requirement occurs in a collaborative manner with the whole team.  This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement. 
From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team.  As an example, this could be in a grooming, refinement, agile release planning, or sprint planning event where the highest priority requirements are discussed and fleshed-out with the team’s input.  During this session, the collaborative discussion may focus on the following: 
  • Understanding why it is a high priority
  • Validating/updating the User Story is in Canonical Form (or defined form)
  • Understanding the business value and customer perspective
  • Considering technical details
  • Describing acceptance criteria
  • Identifying unknowns and risks (each should have an action to investigate and mitigate)
  • Identifying what is out of scope
  • Identifying dependencies
  • Decomposing epic to user stories or each user story to tasks
  • Providing sizing (e.g., story points, etc.)

As the collaborative discussion ensues, the requirement gains more clarity, where there is a team understanding of the work.  As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement.  At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue.  There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements.  Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it. 
Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach.  Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.
Categories: Blogs

Five links on Product ownership

I advocate widening product ownership to a team.

@jeffpatton

henrik.signature

 

 

 

I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading! Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.


Categories: Blogs

Empirical “Certification”: Invest in Results

Partnership & Possibilities - Diana Larsen - Sat, 06/14/2014 - 19:04

Photo Credit: freeparking via Compfight ”https://creativecommons.org/licenses/by/2.0/

If you’re in a particular Agile crowd, “certification” is a dirty word.

On the other hand, the Human Resources/People department in your organization looks for certifications on your resume, asks about them in job interviews, and you may get promoted or better compensated party through the accumulation of certifications. Getting “certified” as a user of a tool, or as a signal of skill acquisition may give you a personal boost as well.

So, what’s with the dirty word? What’s not to like about certification?

Well, Jim Shore has written about this – extensively. He’s even debated the merits of it in public forums.

We think anyone can agree that having the piece of paper may not accurately reflect your skillset.

The Agile Alliance opinion on the matter is that certifications should be skill-based, difficult to achieve, and not a primary reason to hire.

So in this storm of differing opinions about the upsides, downsides, and current realities about certification. It’s easy to forget the most important missing elements.

  •  Where am I on my Agile skill journey?
  •  What have I just mastered?
  •  What skill do I need to work on next?

Without this fundamental guiding compass, of “where have we come from?” and “where do we need to go next?”, Agile teams stagnate, founder, and drown in the swamp of opinions, skills, practices, philosophies, and so on, that comprise the current state of Agile.

Point being, if “Agile done well” was simple, we wouldn’t be having this conversation. Anybody could do it. No problem.

By having the conversation, we can simplify the complex and create a compass for navigating the swamp.

Even better, as more of us make it through, we begin to beat a series of paths through the swamp that work for most teams most of the time, leaving the Agile landscape better than we found it. Safer. More fun. More “this is the best job I’ve ever had.” More able to deliver value.

In five years, the Agile landscape may look more like a garden than a swamp.

When you attend the Agile Fluency™ Project workshop, we won’t certify you, but you will become intimately familiar with the Agile Fluency model and the best of good practices. The model will empower you to evaluate your team and the teams of others according to their behaviors and the results they achieve. You will know just where you are coming from, where you need to go next, and the investment in skills and gear to navigate the swamp. You’ll be able to help other teams find the same knowledge. And the freedom that it brings.

Our goal is to turn the Agile community itself into the informal “certifying” authority. Your peers around you will see the results you deliver. They will look for ways they can help you become better and how you can help them.

Join us in September, and we’ll build this together.

Categories: Blogs

Mission, vision, strategy, doctrine

You don't achieve a vision; you achieve a mission.  You aim toward a vision.  You don't achieve a strategy; you apply a strategy to aim toward a vision to achieve a mission.

A mission defines what success is and therefore the scope of the endeavour.  It does not define how that success should be achieved.

A vision has to be something that creates a concrete image in people's minds.  Otherwise, it's obviously not a vision.  The concrete image clarifies what we believe mission success looks like.  A"vision statement" that creates no images is more likely to be a mission statement.

It may not be necessary to worry too much about separating vision and mission.  You really just need something that defines what you're aiming towards.  The rest is strategy, tactics, and adaptation.

Underlying it all are your fundamental assumptions and beliefs about how the world works, otherwise known as doctrine or culture.
Categories: Blogs

The Art of Learning and Mentoring

TV Agile - Thu, 06/12/2014 - 21:54
Similarly to design patterns, present pedagogical patterns solutions to recurring problems in a given context. The wider context for the pedagogical patterns is teaching and learning, especially of technical subjects. In this session, I want to explore how pedagogical patterns can help every individual to get better every day. Although we are often unaware of […]
Categories: Blogs

Efficiency, Productivity, and Effectiveness

Agile In Action Blog - Staffan Nöteberg - Thu, 06/12/2014 - 20:29

In the area of time management – or attention management which is a more accurate term – the three words efficiency, productivity and effectiveness are sometimes misused as if they were interchangeable. And if they are not blurred in that way, they are often wrongly considered as three competing horses, where you have to make a bet on one and not the other two. However, their mutual interdependency is strong.

  • Efficiency is often about speed. How fast can you execute a sub procedure? And even better: how fast can you execute the very same sub procedure one trillion times? More general it’s about consuming as little resources – doesn’t have to be time – as possible, while executing your sub procedure. An efficient person or organization excel and doesn’t waste any energy, time, or resources. But you might not deliver anything in the end.
  • Productivity is about creating a complete product. The result of your work is a whole; a thing that can be used. Efficiency is very important for productivity. Suppose that a mail is a product. The mail must at least consist of a letter and a stamped envelope with the receiver’s address. Efficiency without productivity is to impressively fast create 100 stamped envelopes, but no receiver’s address and no letter. It would be more productive to produce 10 complete mails with letter, stamp and address, in the same span of time. Low efficiency impedes productivity. If you write the addresses really slowly, then in the end of the day you might only have produced one single mail. Productivity is the ratio of produced output to supplied input. If you never ship anything, then produced output and the ratio is zero, no matter how hard you’ve worked.
  • Effectiveness is about creating products that matters. I mean things that add value to other contexts, systems or people. Productivity is very important for effectiveness. Productivity without effectiveness is to write a fabulous business letter, and then send it to 100 random people around the world. The effectiveness is increased if you send the letter to the people who can boost your business. Low productivity impedes effectiveness. Even if you create complete mails, they don’t add any value – cause desired effect – if they’re not sent to the right persons.

So, effectiveness relies on productivity. And productivity relies on efficiency. In a pull based attention management method, you start with effectiveness. Your choice of intended effect will guide you to the best kind of productivity, which in turn will help you see what sort of efficiency you need.

Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC


Categories: Blogs

21 Tips on Choosing a Sprint Length

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Many teams that I work with choose their Sprint length without too much thought.  Often enough, that’s okay and it works out.  But, in some cases, it helps to think clearly and deeply about what length of Sprint to choose.  Here are 21 tips on choosing a Sprint length.

  1. Don’t ever go longer than 4 weeks… if you do, by definition it’s not a Sprint anymore.
  2. Scrum is about fast feedback – shorter Sprints mean faster feedback.
  3. Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
  4. High-performance teams need pressure to form – shorter Sprints provide pressure.
  5. Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
  6. “False” Sprints such as “Sprint 0″ or “Release Sprints” may feel necessary if your Sprint is too short – try to avoid the need for false Sprints.
  7. If you have lots of interruptions that are disrupting your Sprint plans, shorten your Sprints to match the average frequency of interruptions… and then just put them on the backlog.
  8. If you feel like you team starts out by working at a leisurely pace at the start of a Sprint and then “cramming” at the end of the Sprint, then shorter Sprints will force the team to work at a more even pace.
  9. Don’t lengthen your Sprint to fit the “size” of your Product Backlog Items… instead, get better at doing “splitting” to make the items smaller.
  10. Small failures are better than large failures, shorter Sprints help.
  11. If you are using Agile Engineering practices such as TDD, you should probably be able to do Sprints that are 1 week in length or less.
  12. 2-Week-long Sprints are most common for IT and software product development.
  13. Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.
  14. Teams go through the stages of team development (forming, storming, norming and performing) in fewer Sprints if the Sprints are shorter.  E.g. 5 Sprints if they’re 1 week long, but 20 Sprints if they’re 4 weeks long.
  15. If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.
  16. Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.
  17. Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
  18. If you are doing a project with a fixed release date/end date, then make sure you have at least 6 Sprints to allow for sufficient feedback cycles.  More is generally better which means shorter Sprints.
  19. If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.
  20. Sprints need to be long enough that Sprint Planning, Review and Retrospective can be meaningful.  A 1-day Sprint would allow a maximum of 24 minutes for Sprint Planning, 12 minutes for Review and Retrospective each.
  21. When a team is new, shorter Sprints help the team learn its capacity faster.

Author’s Note: this is one of those articles where I thought of the title first and then worked to make the article meet the promise of the title.  It was tough to think of 21 different ways to look at Sprint length.  If you have any suggestions for items to add, please let me know in the comments (and feel free to link to articles you have written on the topic). – Mishkin.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Simplicity is the Ultimate Enabler

J.D. Meier's Blog - Thu, 06/12/2014 - 18:11

“Everything should be made as simple as possible, but not simpler.” – Albert Einstein

Simplicity is among the ultimate of pursuits.  It’s one of your most efficient and effective tools in your toolbox.  I used simplicity as the basis for my personal results system, Agile Results, and it’s served me well for more than a decade.

And yet, simplicity still isn’t treated as a first-class citizen.

It’s almost always considered as an afterthought.  And, by then, it’s too little, too late.

In the book, Simple Architectures for Complex Enterprises (Developer Best Practices), Roger Sessions shares his insights on how simplicity is the ultimate enabler to solving the myriad of problems that complexity creates.

Complex Problems Do Not Require Complex Solutions

Simplicity is the only thing that actually works.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“So yes, the problems are complex.  But complex problems do not ipso facto require complex solutions.  Au contraire!  The basic premise of this book is that simple solutions are the only solutions to complex problems that work.  The complex solutions are simply too complex.”

Simplicity is the Antidote to Complexity

It sounds obvious but it’s true.  You can’t solve a problem with the same complexity that got you there in the first place.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“The antidote to complexity is simplicity.  Replace complexity with simplicity and the battle is three-quarters over.  Of course, replacing complexity with simplicity is not necessarily simple.” 

Focus on Simplicity as a Core Value

If you want to achieve simplicity, you first have to explicitly focus on it as a core value.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“The first thing you need to do to achieve simplicity is focus on simplicity as a core value.  We all discuss the importance of agility, security, performance, and reliability of IT systems as if they are the most important of all requirements.  We need to hold simplicity to as high a standard as we hold these other features.  We need to understand what makes architectures simple with as much critical reasoning as we use to understand what makes architectures secure, fast, or reliable.  In fact, I argue that simplicity is not merely the equal of these other characteristics; it is superior to all of them.  It is, in many ways, the ultimate enabler.”

A Security Example

Complex systems work against security.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“Take security for example.  Simple systems that lack security can be made secure.  Complex systems that appear to be secure usually aren't.  And complex systems that aren't secure are virtually impossible to make either simple or secure.”

An Agility Example

Complexity works against agility, and agility is the key to lasting solutions.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“Consider agility.  Simple systems, with their well-defined and minimal interactions, can be put together in new ways that were never considered when these systems were first created.  Complex systems can never used in an agile wayThey are simply too complex.  And, of course, retrospectively making them simple is almost impossible.”

Nobody Ever Considers Simplicity as a Critical Feature

And that’s the problem.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“Yet, despite the importance of simplicity as a core system requirement, simplicity is almost never considered in architectural planning, development, or reviews.  I recently finished a number of speaking engagements.  I spoke to more than 100 enterprise architects, CIOs, and CTOs spanning many organizations and countries.  In each presentation, I asked if anybody in the audience had ever considered simplicity as a critical architectural feature for any projects on which they had participated. Not one person had. Ever.”

The Quest for Simplicity is Never Over

Simplicity is a quest.  And the quest is never over.  Simplicity is a ongoing pursuit and it’s a dynamic one.  It’s not a one time event, and it’s not static.

Via Simple Architectures for Complex Enterprises (Developer Best Practices):

“The quest for simplicity is never over.  Even systems that are designed from the beginning with simplicity in mind (rare systems, indeed!) will find themselves under a never-ending attack. A quick tweak for performance here, a quick tweak for interoperability there, and before you know it, a system that was beautifully simple two years ago has deteriorated into a mass of incomprehensibility.”

Simplicity is your ultimate sword for hacking your way through complexity … in work … in life … in systems … and ecosystems.

Wield it wisely.

You Might Also Like

10 Ways to Make Information More Useful

Reduce Complexity, Cost, and Time

Simple Enterprise Strategy

Categories: Blogs

Agile Cadabra

Tyner Blain - Scott Sehlhorst - Thu, 06/12/2014 - 18:08

David Copperfield doing a card trick

Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. Adopting an agile process does not let you magically have a more successful product. What makes agile powerful is also makes it dangerous.

Triage and Urgency

One tenet of agile is to make decisions at the last responsible moment.

Following this powerful and easy-to-remember mantra reduces the risk that you are wasting time on unnecessary work. This approach also maximizes the opportunities to better inform your decisions and actions. By delaying when you do any particular activity, one of two outcomes is created. Either the activity is never done, or the urgency of the activity grows until the penalty for delaying is larger than the risk of wasted effort.

There is always more work to be done, than can be done. Product managers and product owners know there is always more work to be done. Either implicitly, or explicitly, a product roadmap is a plan built on a series of hypotheses. There is always an opportunity to validate or refine every one of those hypotheses. The art of good product management includes having good instincts about which hypotheses embody too much risk, and which ones are solid (enough).

Every day’s work, when you’re being agile about it, should start with the question – “what is the most important thing for me to work on, today?” There’s a problem, not with the concept, but with the application. Most people conflate urgency with importance. There’s even a matrix to help people deal with this. Combine this with the “last responsible moment” mantra, and urgency becomes the trigger in their triage process.

rolling a coin across your knuckles

The weakness of an urgency-driven triage-based approach is that it only looks at one side of the coin. Triage helps you avoid wasting time on unneeded activities. It does not prevent you from skipping needed activities. That’s the other side of the coin – important stuff which gets ignored because it never develops enough urgency until it is “too late.”

Ever heard of a team who deferred creation of an automated test harness because everyone is too busy fixing bugs? What about a team which has too much on their plate to consider refactoring? Too busy grooming the backlog for the next sprint to invest in developing a strategy?

This happens because our intuition about urgency is not good enough to balance the immediate with the long-range. Evolution wired us to respond to hungry predators – urgent problems. It seems reasonable to me to expect us to be weak at estimating the “actual urgency” of activities with limited immediate benefits and very immediate costs. The expression dig your well before you’re thirsty keeps coming to mind for me.

Game Theory

So, it turns out you can play a variant of the prisoner’s dilemma  with your future self, by looking at the benefits and costs of your actions, both today and in the future. You do this by imaging the cost-benefit to your present self versus your future self.

Paul Young’s recent (and good) article about the conflict between agility and strategy is what inspired me to explore the following scenario.

Consider the bi-weekly choice you have to make as a product manager / owner: Do I fill up the backlog (Scrum process) with the best stories I can today, keeping the development team busy; or do I spend two weeks improving my strategy by getting and processing information about the market?

[Note: I know I'm creating a false dilemma to amp up the drama. Pretend I'm being reasonable and talking about changing the proportion of time being spent on each activity]

If I fill up the queue of work for the team – to the best of my present ability, based on what I know right now - I incur a small immediate cost – increased angst and worry about the quality of my strategy – and I receive a large immediate benefit – a content development team. My future self risks a large future cost – the strategy was wrong – and a small future benefit – the development team has been busy the whole time.

If I make the other choice – to invest in understanding my market, here’s what happens. My present self receives a small immediate benefit – satisfaction in an improved or validated strategy – and incurs a large immediate cost – my boss complaining about an idle development team. My future self will receive the large future benefit of a successful product and an ultimately successful and happy development team, if he doesn’t get fired first.

The immediacy and visibility of “wasting” the team is obvious*. In the grand scheme of things, it is also a very small cost. The uncertainty and abstractness of having the wrong strategy is vague and nuanced.

*I don’t really accept the premise that not building product is _always_ waste. If you’ve got a tree to chop up for firewood, how much time do you spend chopping, and how much time do you spend sharpening your ax? If I need to understand my market better, I can ask the team to sharpen their axes. Their time won’t be “wasted.”

Rich Mironov offered a great tip to me too – have the team pick what they work on for the current sprint. If you’ve shared your insights with them, they are likely to make on balance good choices, so the “waste” of any bad choices is further reduced. Thanks, Rich!

There’s a pretty good analog in how we approach diet and exercise. The small (but visceral) sacrifices we make in the present determine the large (but presently intangible) results we realize in the long run.

In reality, this is not an either-or decision, but a time-allocation decision. What percentage of your time do you spend on understanding your market? Or how much time do you “steal” from the tactical urgent stuff, to work on the strategic important stuff?

Because we under-appreciate the value of improving the strategy, and over-index the cost of immediate issues, product people (owners, managers, champions, presidents) will be biased towards addressing the urgent. Behavioral economists have a term for this – hyperbolic discounting .

This is what makes any process which amplifies or leverages urgency a bit dangerous. It biases us towards further under-emphasizing the not-visibly-urgent, yet still important.

niagara falls barrel rider

Conclusion

Agile can be fantastic for your company.  Agile is not, however, magic – if you do it wrong, and under-invest in strategic thinking, you could actually be worse off than if you had stayed in the waterfall.

Post to Twitter Post to Facebook

Categories: Blogs

How do you transform your Agile into the Best Job Ever!

Partnership & Possibilities - Diana Larsen - Thu, 06/12/2014 - 16:45

 

There’s this thing…as Jim (James Shore) and I (Diana) have mentioned before, in the early days of Agile we would visit teams and hear, “This is the best job I’ve ever had. I love this work.”

People who were doing Agile (usually Extreme Programming) were excited about it, they shared it with others, who did it, and got excited.

But at some point, someone shared it with someone who got excited about it and shared it but didn’t DO it, so their sharing lost a bit of fidelity, like a copy of a copy. Hearing about a thing is not the same as doing a thing.

Both the virtuous cycle (doers sharing with doers) and the vicious cycle (talking about-ers sharing with talking about-ers) continue, but now more than ever in the internet age, talk spreads faster than action.

We’re drowning in ideas, opinions, gossip (“Tell me how you failed at Agile”) and complaints about Agile, and have less opportunity to experience the real deal. At many conferences (and now through an Agile Alliance program), Experience Reports are a sought after item. People still want to hear from the successful doers.

And yet, the doing is so small in comparison to the talk, that the effective practice of Agile is in danger of being overwhelmed by the talk.

In other words, Agile is becoming a way of achieving only, “Well, my job doesn’t suck as much as it used to.”

In yet other words, Agile is in danger of being redefined as poorly done Agile.

So what to do? To achieve Agile done well and the best jobs ever, we need to feed the virtuous cycle and starve the vicious cycle. We need doers working with doers. We need the Agile Fluency Project.

We need you. Sign up. Beg, borrow or steal the time and money and join us in September.

 

Categories: Blogs