I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not? (Continued)
Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.
But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. (Continued)
Everything should be made as simple as possible, but no simpler. — Albert Einstein
Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup. It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work. From there it spawned a long discussion about various ways to estimate the work and commit to it.
To me, most of these approaches to estimation are more complicated than is necessary. Some go into detailed calculations that are far more complicated than what most teams do. I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. (Continued)
How long does it take to take a team from where they are to becoming an Agile team? Of course, that depends on many things, including where they are and how badly they want to succeed at Agile. It’s reasonable to think they can make a transition in six short months.
If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer. If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.
A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development. The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India. (No mention if all of the workers in India were in the same place.) I’m not picking on this individual. I’ve heard similar stories many times.
It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture. On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects. In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines. Why do it this way? (Continued)
Yesterday was a day of mistakes. Not so much making mistakes, but talking about them. It started with Bret Pettichord’s tweet
Agile requires the courage to make mistakes in front of others and the maturity to admit them when they happen.
Maybe you’re starting your first Agile project. You’ve read books and blogs. You’ve had training. You think you’re ready, but it’s still a daunting prospect. There’s just so much to remember—so many details.
Here’s a little cheat sheet. Forget all the details and the various ways you can implement Agile for the moment. Let’s simplify the picture. There are just three essential legs that your Agile project needs to stand. Get those in place, and you’ll do OK. Keep improving all three, and you’ll do fantastically! (Continued)
Ever since I experienced the “Where Are Your Keys” language fluency game with Willem Larsen, I’ve been thinking about how to apply the concepts to learning other than languages. One of the fascinating concepts I gleaned from this game is the separate dimensions of proficiency and fluency. The proficiency scale that Willem uses is based on the ACTFL guidelines of Novice, Intermediate, Advanced, & Superior. Willem gave a memorable colloquial description of these guidelines in relation to a party: (Continued)
Thanks to Esther Derby’s amplification on Lining Up Priorities, I came across Tony Tjan’s blog posting, Four Simple Ways to Make Your Employees Happier. Tony says,
There is a very simple secret to long-term employee loyalty and retention and it is not money, perks, or stock options. It’s giving them meaningful roles.
This is not an idealistic motherhood-and-apple pie dream, but rather a basic condition of human behavior and psychology that many businesses and leaders often forget: people are driven as much or more by intrinsic meaning as they are by extrinsic rewards.
This is, I think, a little-discussed benefit of the self-management that’s found on successful Agile teams–the employees are motivated by creating value rather than just by pay and perks. People want to do well for you. Give them an opportunity and an environment where they can do so.
A new installment of the Agile Tool Podcast is available, where Bob Payne and I talk about Team Rooms. Please let us know what you think of this.