Branching and Integration Time

Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a branch or in a developer’s workspace. Discussions about improving pace of development often veer into arguments about branching. Arguing about whether branches are good or bad will distract you from the more basic question of “Do changes get integrated and tested rapidly enough to ensure the rate of delivery we want?”

Integrating too slowly is the main challenge to agile development. Slow integration makes it harder to show incremental progress and maintain an always working code line with valuable features. Frequent integration helps the team deliver incrementally and maintain working software. Your process should help you to integrate quickly so that you can deliver value at a good pace.

The ideal integration frequency varies from team to team. Merging once a day is good, more frequently can be better, but too often can cause churn and overhead if you aren’t doing it well. Team and planning dynamics are key decision factors, but some things are universally true: small frequent commits improve reliability, changes that move the design forward are more valuable than trivial changes. These factors often lead to once a day as a good initial target, but each team needs to decide what values of “small” and “frequent” work for them. (Retrospectives are a good forum for exploring that question.) Automated testing is essential to moving quickly even though it can add a small increment of time to the commit interval in the short term.

Getting this to work well can be challenging, but it is doable. Small useful increments and effective tests are easier than many believe. Though you may need to change your mindset.

Branches and reviews can improve collaboration for both co-located and remote teams. So rather than starting with a “branch or not” conversation, start with an integration rate goal and evaluate how long it takes code to get into production. The next post will talk about why branching can have advantages for your team.

(This is adapted from an earlier Techwell article)

Perceived Safety and Branches

Branches are often used with the goal of improving stability. This going wrong is often the source complaints abut the use of branching. This post briefly examines the rationale behind branching some non Main Line branching strategies.

Workspaces and Delays

A Brief Detour from talking about branching. There are risks with branching, there are other paths that lead to deferred integration, and all the issues that arise from that.

The Trouble with Branching

Code Lines defined terms, Why Code Lines Matter motivated why SCM Process matters, and the post addresses a major risk people see in using branching.

Why Code Lines Matter

Code Lines defined some terms. Here I’ll start getting into how SCM and Version Management concepts affect your day to day work

Code Lines

My last post introduced the series. This post defines some terms and sets the stage for discussing the value of simple branching for agile teams

It's About Time: Branching and Integration

This post kicks off a series of articles about the role of branching on an agile software development team. Since Software Configuration Management Patterns came out quite a while ago, it seems like time to revisit some of the concepts in it. They are still relevant, though a different approach to explaining how to apply them might be useful.

Review: Range: Why Generalists Triumph in a Specialized World

Range: Why Generalists Triumph in a Specialized World by David Epstein
My rating: 5 of 5 stars

In Range David Epstein explains that while specialization can be valuable in some circumstances, “Range” is both important and undervalued. There are many others where having breadth of experience leads to better solutions to problems, particularly in more complex domains that one typically encounters in knowledge work.

The idea of range resonates with the idea of Cross Functional Teams of T-Shaped people (breadth of experience with depth in some areas) which Scrum and Agile advocate. In the context of an agile team, such a team solves the problem of maintaining the flow of work, as you are less likely to find work in your backlog that is blocked because of a local of someone who can do it. Epstein explains that such teams lead to better solutions as well.

The discussion of the importance of “range” goes against many beliefs people have about the importance of having deep knowledge and getting a head start on acquiring it. Consider the push to start training for sports early or to develop deep skill in an academic discipline. Even in hiring, people with a mix of skills don’t seem to fit neatly into org charts, even as work requires a mix of skills, and a desire and ability to broaden ones areas of expertise.

As someone who has a wide range of interests, and who likes to find connections between seemingly unrelated domains I very much enjoyed and appreciated Range. It’s a well written book, with a mix of assertions, stories, and references to data, along with quite a few notes and sources for those who are skeptical and want to dig deeper.

If you are work in a knowledge area, or are thinking about how to influence a child’s learning path, Range is worth a read to help you understand the context of when breadth adds value.

View all my reviews

Designing your life: Design and Agile Tools Applied to Life.

Designing your Life: How to Build a Well-Lived, Joyful Life by Bill Burnett and Dave Evans explains how you can apply design thinking to life choices. While the true test of the information in the book is to do the exercises and embrace the process, and look at the results (which I have not yet done) I finished the book with an excellent understanding of the possibilities and the feeling that I could use the tools to better understand my goals. Participating in a mini-workshop that Bill Burnett helped to validate that the process can be very powerful. A lot of work, but powerful.

As I mentioned in an earlier Techwell article (which was based on an interview) many of the concepts here may be familiar If you are a student of agile principles. Some of the exercises are reminiscent of those in Innovation Games. There is an exercise that is reminiscent of a career timeline exercise that Johanna Rothman has proposed, and the discussion of job searches and job descriptions is very consistent with some of what Johanna has written about the subject.

There are other elements that sounded familiar as well. The discussion of problem reframing will be familiar to those who work with software requirements, and the discussion of the qualities of a good “design team” will be familiar to anyone who has studied teams and read books such as Extraordinary Groups. Even if the concepts are familiar, there is value in seeing them applied to life design.

That the tools are familiar should not lead you you dismiss the value of the book. (After all, one could argue that much of the “agile toolbox” derives from other disciplines.) Like any tool box, tools can have many applications and it's useful to have a guide to how to use a tool to solve your problem with the right techniques, and to understand that there are versions of the tool that are more finely tuned to your purpose. I hesitate to say "solve your problem efficiently" because life design is neither a problem with a single solution end point (it's a process) nor is it simple. By applying the collection of straightforward steps in this book you can start on the path to understanding how to design a like that is congruent in all dimensions that matter.

Regarding solving as compared to exploring, the authors emphasize that there is difference between engineering problems and design problems is that design problems in that engineering problems are more about solving, and design ones about building forward. While I believe that to be a good engineer you need to understand design, I agree that there are different perspectives, and engineers don’t often switch between “explore options” and “solve a defined problem” appropriately.

This is an easy to read book that can be useful in helping with evaluating both the big picture and specific aspects of your life. You may even gain some insight into problems related projects, since the tools are similar. Reading the book is valuable. Working through the exercises with a team can be more so. The book is full of are exercises and is supplemented by a web site with worksheets and other resources to use. This is an easy to read book that can be as useful as you want it to be.

Starting and Closing Agile Retrospectives with People in Mind

One of the more powerful aspects of agile software development methods such as Scrum is that they acknowledge the importance of individuals and their interactions in delivering quality software. As much as it is important to review and adapt the product backlog by having sprint review meetings at the end of each sprint, it is also important to have retrospectives to inspect and adapt how the Scrum process works on a team. The Sprint Review is about the tasks and scope (the “What” of the sprint). The Sprint Retrospective is about the Scrum process (the ‘How”). Sadly, many teams miss out on some value by glossing over the parts of a retrospective that acknowledge the human elements of the scrum process. By using some simple techniques teams can improve their retrospectives by putting more emphasis on people.
Allocating time for a retrospective every 2 weeks (if you use 2 week sprints) can be a challenge. The 5 step structure that Ester Derby and Diana Larson describe in their book Agile Retrospectives is an excellent framework for making good use of retrospective time. The steps are:

• Set the Stage, where you introduce the plan for the retrospective, and help people move towards a mindset that will help identify problems
• Gather Data, where you collect information about what went on during a sprint. Some of the data collection can happen before the actual meeting, but people will likely think of information to add.
• Generate Insights, where you identify patterns and connections between events, and start to consider why things may have happened.
• Decide what to do, where you collect ideas for things to do going forward, and then focus on a handful to explore in detail.
• Close, where you review action items, appreciate the work people did, and perhaps discuss the retrospective.

These steps create an environment where people can feel safe, and help the team to explore the really impediments to improvement. Often teams skip steps, merge steps, or don’t consider whether the exercises they use at each stage move the process forward. Using structured exercises like those in Derby and Larsen’s book help keep the retrospective focused. Another common tendency is to problem solve too early, combining the Gather Data, Generate Insights, and Decide What to do steps. These mistake is often self correcting, as teams discover that they come out of retrospectives with actions that address superficial problems.
A bigger problem is when teams skip the steps that address the humans on the agile team. For example, particular, some facilitators skip over Setting the Stage, or Closing, in an effort to allow time for the “significant” parts of the meeting. While only a small part of the meeting time, the Setting the Stage and Closing steps, are quite valuable in terms of impact.
Setting the Stage for the retrospective can take just a few minutes, and can improve the effectiveness of the entire meeting by creating an environment where people feel comfortable collaborating. There are many reasons people may not contribute, including simple shyness or lack of attention, or even concern about getting blamed for something. Setting the Stage correctly can help engage the team more fully in the process by bootstrapping participation and emphasizing that the retrospective is about improvement not blame.
I often start a retrospective with an exercise that involves going around the room and giving people a chance to say a word or two about something, for example “one word about how they feel the sprint went”, or “how they feel about the retrospective ”, or even “one thing about yourself that you’d like you share with the team.” This often helps people step out of a spectator role. Note: Always give people the option to say “Pass,” since forcing people to reveal something about themselves is counter to the values of a retrospective; even saying “Pass” gets people engaged in the process.
To reenforce the constructive goals of the meeting, teams I work with sometimes start retrospectives by having someone read The Retrospective Prime Directive, and ask everyone if the agree. While some people initially feel like this process is a bit silly, may teams find it valuable, and make an effort to rotate who reads the Prime Directive.
The other part of the retrospective that can help maintain connection is the Close. I encourage teams that I work with to incorporate appreciations into their closings. Appreciations are a structured way of acknowledging the work someone did during the sprint. A quick appreciation can really help people feel engaged and valued, and the process helps the team consider the value each brings to the group.
By setting the stage and closing your retrospectives well you can help your team get more value out of retrospectives, and help form a stronger, more effective team. Inspect and Adapt isn’t just about the tasks, it’s about the how the team works too.

Giving, Taking, and Being Successful

I’ve been making good use of my commute time recently, catching up on reading, and in particular, the stack of physical books on non-fiction topics that are somewhat relevant to my work. I was making good progress, only to have new, interesting stuff cross my path. One Sunday morning in December I caught part of an interview with Adam Grant on On Being. I wasn’t familiar with Adam Grant before this, but I’m extremely glad that I caught the show. I soon got a copy of Give and Take by Adam Grant, and I read his next book Originals shortly after it came out. In the spirt of giving, and of the serendipity that led me to learn about Adam Grant, I’ll also mention some of the other books Give and Take brought to mind.

I read Give and Take by Adam Grant as last year ended. This is was a great book to end one year and start another with, as it got me thinking about the value of generosity, not just to others, but also to your self.

Grant explains how givers (as opposed to takers and matchers) get ahead in the long run and also help their teams succeed. Teams which have people who have a positive attitude towards helping others in small ways often do better in the end, and in the long run the helpers are more successful too. This goes contrary to the idea that the way that you make progress is to focus on what you need to do. The reality is that for most complex knowledge work, you can’t do it all yourself. As Austin Kleon’s Steal Like an Artist says, the best creativity is inspired by the work of others. Helping others both enables the larger unit to make forward progress, as well as making it easier for you to get help with your work when you need it.

The idea of people who make the team better, even when their short term contributions don’t seem as significant brings to mind "Catalysts" as mentioned by Tom Demarco in Peopleware.( Slack, another book by Demarco, also came to mind because of it’s discussion of the willingness of volunteers to contribute to efforts). This book also brought to mind another recent book, Invisibles, which discusses the “invisible” people who make things happen, and who are happy to be out of the spotlight. I don’t know if I can say that all invisibles are givers but I would not be surprised if that were true.

Giving can have limits. Many people struggle with how to balance the idea that being helpful and generous is good, while not overcommitting themselves. Grant explains how to be a giver and not overextend yourself. Likewise, givers often have a hard time taking care of themselves by leveraging their tendencies to advocate for others. Both approaches involve an an “otherish-strategy,” which is one of the more interesting (of many interesting) concepts in the book.

To those familiar with Jerry Weinberg, this will seem related to the Airplane Mask metaphor in Secrets of Consulting. Grant gives a more detailed model of how to think it through. Weinberg’s metaphor is still good to keep in in front of mind though.

This book resonated with me on many levels. There are lessons here that will help me in my roles an agile software developer, manager, member or my town community, and member of my UU church community. The information here resonates with, and explains, many things I've learned from Gerald Weinberg, about technical leadership (as in the book Becoming a Technical Leader, and Gil Broza about the agile mindset, and many other useful things I've read about how to be an effective team member.

This book will help you to understand why that's true, how you can be a more effective giver, and how to encourage others to give, so that you can be part of a more effective team or community. As Adam Grant says, we need more givers.

update March 28, 2016: Fixed reference to the correct Tom DeMarco book. I mentioned Slack. I meant Peopleware.

---

_ _

Team of Teams: An Unexpected Source of Agile Inspiration

One can find insight in unexpected places. Team of Teams by General Stanley McChrystal et al is a book about dealing with organizational complexity, written by a general, which uses the war against Al Queda as a common thread. I was somewhat skeptical that I could find information here about software teams that I'd find immediately useful, regardless of how interesting it was. I was wrong. In addition to the advice I was expecting to read about team dynamics, I gained some insights that I thought would be immediately applicable to scaling Scrum Teams.

Fairly early into Team of Teams the authors explain that this is not a war story. While it's true that the common thread in the book is how General McChrystal worked to get the army more able to adapt to a decentralized, agile enemy, there are are also stories from commercial aviation, NASA, and corporate America. While there is a fair amount of military history in this book, there is also a discussion of the history of manufacturing process improvement, office space, and even personal stories about gardening.

The message in this book is that command and control structures don't work in complicated, information rich environments that deal with complex problems. He defines complicated as "having many parts" and complex as having many interactions. To get things done in this kind of environment you many need to cast aside what you are used to thinking of an efficient approach.

McChrystal draws a contrast between being resilient and being robust: The more you optimize a complexy system for a specific goal, the less resilient it becomes. Likewise efficiency isn't always better than adaptabilty: you can build a system that is good at doing things right, but is too inflexible to do the right thing. Redundancy and overlap can enable adaptability; an efficient system that does the wrong thing doesn't add value.

Had McChrystal been delivering this message in the context of a corporate enviroment, you might dismiss this as another instance of someone who is in an environment suitable for agile singing the praises of agility. That he's talking about battle command situations, the canonical top-down environment, gets your attention. As with Turn the Ship Around this provides evidence that an "agile" approach can work in more circumstances than you might guess.

At the core of the book is the philosophy that too much control of information and decision making slows down a group's ability to react to situations. The situations described in the book were ones where the risks of acting too slowly are higher than the risks of competent peope making judgment calls. Automomous decisions are usually good as long as they are visible and shared. While most business decisions don't have the same life or death implications of those made in a war zone, slow decision making can have a business cost, and potentially a morale cost if people feel undervalued and micromanaged.

McChrystal advises us that it's not enough to "empower" people in name only. Automony and delegation only work with a clear understanding of a common purpose. Communication channels and shared information are important to both sharing the common purpose and giving people the tools to act in a manner consistent with that purpose. One technique he used was to provide for open office spaces. McChrystal acknowledges that open office space only improves team productivity when everyone is working on related problems, and that open office space as a way to be "space efficient" is productivity inefficient. Video conferencing for his troops was also important, as his teams needed to communicate with others in remote places. As someone who works in a company with people in multiple locations, the stories of the challenges of setting up video conferencing sounded all too familiar. That they were successful in a low bandwidth war zone situation was encouraging.

The book also had some insights about scaling teams that had an implication for scaling Scrum. While it's appealing to think of projects at scale as hierarchical, each level of hierarchy hides information. That can be fine when everyone knows what other teams need to know and not know. But that kind of knowledge is rare. McChrystal's approach to scaling is that everyone needs to know someone on every team so that information will flow organically.

I found both inspiration for seeking ways to improve, and practical advice about how to structure teams and be an effective manager in this book. While not about agile per-se, I think that there are lessons here that apply to those trying encourage agile adoption in a non-agile situation, and also for those looking to scale agile.

---

Turn the Ship Around: Agile Lessons from a Submarine Captain

I was not expecting a book about working on a Navy submarine to provide insights I could use to help a team be more agile. Having heard recommendations for Turn the Ship Around!: A True Story of Turning Followers into Leaders by David Marquet from both a colleague at work and people in the agile community who I respect, I decided to give the book a look anyway. I’m glad that I did.

I thought that this was be a quick, enjoyable read with many lessons I could quickly employ at work. The chapters are all short and focused, and the author repeats the key themes often enough that they stick. Each chapter is centered around a story, so it’s easy to see that the lessons in the book are based on experience and not just theory. My focus is on working with agile teams, so I found that the lessons applied to that context. Even if you are not doing "Agile, this book highlights the value of an agile, adpative, self-organizing approach can have in any organization, regardless of the overall process.

The book is easy to read, with one key point per chapter, and with chapters being short enough that one could almost always find time to read a complete chapter (and thus gather a coherent lesson). This wasn’t a perfect book. Certain aspects about the writing style I found a bit jarring. While some repetition of key points is helpful, there is a bit too much of it at times. And I found the author’s use of ALL CAPS as a mechanism for emphasis to be a bit jarring. Over these stylistics decisions don’t take away from the value of the book; they just made the reading experience less than ideal. But it’s not hard to get past that, and the engaging stories that the book uses to set the stage for its lessons keep you reading.

The ideas in the book should be familiar to anyone who has spent time studying agile teams. That the author talks about how bottom up, distributed decision making (an aspect of what the author calls a leader-leader approach) can lead to a more effective operation than the traditional (to the Navy) , top-down leader-follower approach that many military and other organizations follow. Processes and checklists have as place to simplify decision making, but only in the context of rational though about your goals. Command and Control has a place, in particular in a military organization, but a more limited one than you might think. Even in critical situations a leader-leader model, where people are applying their training to do what works, rather than working by the book, or blindly following authority, can solve the problem better.

What I particularly found compelling was that this book is full of stories of how a more botton-up, empowering model of leadership can be a better way to work. That this can be true even on a submarine – an environment that is both literally and figuratively high-pressure – , should be an excellent counter to those who argue that we can’t do (agile, self-organizing teams, etc) in my organization. An agile approach is not the best solution for all problems, but agile techiques are more widely applicable than many think.

This work does not exist in a vacuum. The author frequently cites Stephen Covey, the author of Seven Habits of Highly Effective People and the writer of the forward to the book, and also provides some pointers to other resources. Whether you are a manager, scrum master, or just someone involved on a team (agile or not) that doesn’t seem to be working well, reading this book will be a quick and enjoyable path towards finding help in identifying things that might be getting in the way to effectiveness, and also give you a sense of optimism that things can get better with the right approach.

---

Brick By Brick: Lessons from Lego (Book Review)

There is no shortage of business books about companies that lose their way, and then do a dramatic turn around. Some are more relevant that others. Brick by Brick by David Robertson caught my attention because it is about an iconic toy that is, at the moment, popular with people of all ages. The book first came to my attention when we were stopping at a bookstore bookstore in Saratoga Springs, NY last summer. My then 7 year old, a big Lego fan, and avid reader handed the book to me suggesting that I might enjoy it. He was right; I enjoyed reading the book and also learned some useful things.

While I had heard stories about the reasons behind the recent surge in Lego’s popularity, I had not realized both the scope of the changes the company made, and the depth of the problems the company had. Lego’s story is one of a company losing track of it’s core vision while trying to diversify and create market opportunities. Robertson explains the rise and fall, and rise of Lego in an engaging style, while highlighting the key lessons are reader can apply to their orginization.
While much of the book was a great story, it was around the mid-way point that I found items that resonated with me as an Agile Software Development practitioner. One of the insights in the book was that more constraints can make for more creativity. In particular, Lego sets are constructed with many of the same bricks; new bricks are rare, so designers are encouraged to create new models with existing bricks. This isn’t necessarially surprising to someone used to working with constraints (or building with Legos), but it does contradict the sterotype that blank pages are best for creativity.

Also reminiscent of agile adoption is the idea that action that leads to forming new habits is essential to changing a culture. This is much like how agile practices, done well, can help the team form habits that further enable agility.

There were also some interesting lessons in the discussion of how Lego involved community members in the design of new toys. The community related acitivities were managed in a way where the final decisions rested with select people at Lego, rather than in concensus. Deciding how to make decisions is an important decision for every team to make, as Ellen Gottesdiener tells us, and concensus isn’t always best. The formerly top-down company also discovered the power of voluntary commitment. This is an example of how management skills that make sense in the context of volunteers (the community members) apply to workplace management as well. (Tom Demarco also discuses this in Slack ).

I enjoyed reading this book, mostly for the chance to hear the story of the company whose products appear to be even more popular than when I first encountered them as a child. It was an unexpected surprise to also learn a few things that I could apply to help the teams I work with be more innovatiove and productive.

Five Dysfunctions of a Team (Book Review)

I’ve often thought that the hardest part about building a software product was creating an environment where the people on the project can work together effectively. The Five Dysfunctions of a Team kept showing up on recommended book lists and I finally decided to get a copy. I’m glad I did. This quick to read book helped me to remember some simple, yet important, things about how great teams work.

Reminiscent of The Goal and The Deadline, The Five Dysfunctions of a Team spends most of its time teaching its lessons using the example of a fictionalized story of a new CEO joining company in trouble.

The CEO uses the model to help the executive “team” become a team in more than name. Even though the story itself isn’t great literature, since I’ve been in and around dynamics similar to those in the book, I really wanted to see what happened next. (Though a successful ending was never really in doubt.)

There is a brief summary of the 5 dysfunctions model at the end, but the story form really drives the point home better than the 37ish page summary of the model. You could just jump to the summary of the model, but the lessons might not stick, and the power of the simple model might be as clear. What the model description adds is the important point that the parts of the model work as a system, and can’t really be taken independently.

If you’re on an agile team you might want to think about how agile methods both rely on and encourage the elements of the model.

If you are on a team, (or even part of a family) you’ll find value in this book, either as a way to lead others to form a better team, or as a way to understand what’s happening around you so that you can do better on your own, and make the right choices to help you work on a good team.

Essential Scrum and Other Books to Help You be Agile

I’ve read a few books on Scrum over the years. I read Essential Scrum because others at my company who had not gone through Scrum training with Kenny Rubin, and I wanted to use the book aa a vehicle for refreshing my thinking and getting on the same page as everyone else in terms of terminology, best practice advice etc. The book helped with that and more.

Reading this book did more for me than give me a chance to synch up vocabulary. It helped me re-think some practices and consider ways to move beyond my current approach to Scrum and consider ways to do things better.

This book covers the whole spectrum of Scrum related issues from the usual Scrum mechanics, such as how to execute scrum meetings to questions that often leave those adopting Scrum for the first time puzzled such as how Scrum fits in the larger organization, the the role of Managers (yes, there is one), and how to deal with obstacles.

The book has an excellent discussion of the various Scrum roles, and how they work in real situations. (For example, what to do when you can’t have a dedicated Scrum Master). This is a book on process, but it does not let you forget that people and communication are at the core of Scrum.

This is a rather complete book on its own, as it covers the full spectrum and full lifecycle of Scrum from planning to retrospective, and from Portfolio to sprint. Rubin also provides a selection of good references throughout should you want to go deeper. In particular you might want to follow up by learning more about retrospectives by reading Agile Retrospectives or learn more about portfolio management by reading Johanna Rothman’s book.

What was especially interesting for me to see was the chapter on management. With the focus on self-organizing teams and mechanisms for team feedback and improvement, many people either neglect the role of managers, or overlay an approach that can stifle a scrum team. Rubin has an excellent chapter on this topic. You may also want to read Management 3.0 for a broader perspective on what a manager on an agile team is, and Behind Closed Doors: Secrets of Great Management for some excellent day to day advice on managing in any context, but especially an agile one.

This book is different from some other recent books on Scrum. Scrum: The Art of Doing Twice the Work in Half the Time is more about the principles of Scrum, and it’s a great book to inspire you to implement Scrum values, but a book like Essential Scrum is what you’ll need to actually execute. The Human Side of Agile adds to Essential Scrum by guiding you through the interplay between technical and people issues.

Essential Scrum is readable and useful by everyone on the team and in the business, and is a great book to read if you can read only one for now. Essential Scrum can help you adopt Scrum more effectively, or reenergize your Scrum thinking if you are Scrum veteran. There are other books that will want to read as you seek deeper knowledge, but you can’t go wrong with starting with Essential Scrum.

Estimation as a requirements Exercise

I explored the role of estimation in a couple of articles on Techwell recently.

In the first article I discussed how teams balance the cost of estimation (in terms of time it takes) with the value it brings to the project. Some argue that estimation isn't very useful at all, where other's say that it can be useful, but that all stakeholders may not have the same vision of the value estimation brings.

In a follow up article I explore the debate about whether to estimate in hours, which reflects effort, and time, or  points, which reflect complexity. This is a common debate, since many articles on agile advocate points, to step away from the concepts of estimate, and focus on the complexity of a feature, and also to help teams move towards the model of the estimate being valid for the team and not just a particular person. And stakeholders are often concerned about schedule and deadlines, so tend to prefer hours initially.

Different teams will come to different decisions about what works best for them. To me the most important part of the estimation discussion is the part many teams don't have, namely asking (and answering) the question of why they are estimating, and what value the estimates bring to the project given that they are now working with an agile process.

As I think more about what value estimation has brought to teams that I have worked on, I realize that the biggest value is that of having a a discussion of scope. When you have an planning meeting, a few questions come up:

• Why people have different estimates
• Why the estimate is larger, or smaller, than the product owner expected
• Whether the team really understands what the story means.

Give this I'm leaning towards thinking of estimation as being more about requirements definition rather velocity, effort, or even complexity.  To that end, maybe the approach to use is one where you spend all of your planning effort defining stories in terms of small, fixed size units, and your velocity is about how many stories you finish off of a prioritized backlog. I link to a description of what this means in the points and hours article.

I'm  interested in hearing about creative approaches your teams have used for estimation. Please comment on  the Techwell articles, or here if you want to share lessons you have learned.

Lean UX for Startups (Book Review)

I recently received a review copy of another book in Eric Reis's Lean series, UX for Lean Startups: Faster, Smarter User Experience Research and Design. In this book, with a lively, if somewhat irreverent, tone, Laura Klein guides you through the process of using UX as a gateway into finding a market and eventually, success. This book has pragmatic advice on what to do and how to do it now, and more importantly, what not to spend time on. Not just a concept book, this book discusses tools and detailed approaches. Klein addresses many of the concerns people might have about "skipping steps" in order to be lean, and explains the both the challenges and benefits of a lean approach to UX design. The author discusses how UX fits into an agile startup environment.

This book shares some of the irreverant tone of another book geared to people starting a business: The Pumpkin Plan: A Simple Strategy to Grow a Remarkable Business in Any Field. The author's tone takes a bit of getting used to, but the advice is good, and actionable, and the style of the writing emphasizes the "just do it" theme of the book.

UX For Lean Startups has a slightly different audience than the earlier, similarly titled book Lean UX: Applying Lean Principles to Improve User Experience. Looking at the books, it's a bit unclear which one to read. As it happens, Lean UX: Applying Lean Principles to Improve User Experience is more about how to apply Lean Principles to UX design, with an eye toward migrating from a non-iterative UX process to a more iterative, lean, agile process. That book seemed to be geared more towards UX professionals, though anyone who touches UX could benefit from it. Lean UX for Startups addresses the needs of entrepreneurs and members of a startup who want to have a good UX, but can't waste a lot of time and effors on it. I'd reccommend that either individual get both books. But if you are building a startup, this one will give you the most actionable advice quickly.

You can benefit from reading both books. If you want to read one on UX, you might get more out of the Lean UX book. And Maybe read Lean Startup or perhaps the Pumpkin Plan. This book will add information so it is worth a read. The 4 books I mentioned would be a good addition to the library of anyone who is starting a business and wants to deliver value quickly.

Lean User Experience: Using UX on an Agile Project

User Experience is a discipline that has a strange relationship with Agile. On the one hand, traditional UX work involves research, testing, and other steps that seem inconsistent with working in the context of an agile project. It also seems to be a discipline where practitioner often seem to be committed to a Big Design Up Front approach, which is inconsistent with Agile. On the other hand, getting the user experience right seems like an essential part of delivering value. The book Lean UX: Applying Lean Principles to Improve User Experience explains how UX work integrates with agile.

The book combines the themes of The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (including MVP: Minimum Viable Product) with those of user experience and agile methods like Scrum, in a concise, book that can serve both as a quick overview of the concepts which you can read in one or two sittings, as well as a reference for how to apply the process on your team.

This book has stories, templates, guidelines to help you both use User Experience Design in an agile team as well as to use User Experience to help your agile team do a better job of building the right thing. Much of what you'll read will strike you as "common sense," which, sadly, does not translate to common practice in many organizations.

This is a rare book that is information dense, yet which does not allow that information density to compromise readability. The viability of the book as a reference compensates for the one flaw I see in it's presentation of the principles of Lean UX: there are too many principles.

The book starts with a list of 15 (related) principles of Lean UX, which is far more than most people can keep in their head, making it harder to both sell and internalize the ideas. I understand that there is a lot to do to implement Lean UX, but I can't help think there must be a way to distill the 15 principles into 5-7 key ones which incorporate the spirit of the whole set. This may sound like a petty detail, but I suspect that it would be hard for someone not as versed in the concepts as the authors to sell the concept based on those 15. If you can't sell an idea, it is that much harder to break down opposition to it.
The concrete, concise way the authors describe how to implement Lean UX in various environments compensates for this, but since the book started out with an overview of principles, I was initially concerned about how the rest of the book would go. It is worth pushing past the principles section to learn the value of Lean UX, and techniques to use it effectively.

The book will be useful to managers, UX designers and developers and anyone wondering how UX can work in an agile environment. Since user experience is such a central part of the product definition it will also be useful to anyone who simply wants a better understanding of agile product development.

(Note: This review was based on a review copy of the book.)

 

The Human Side of (Agile) Software Development

In  the Sept/Oct 2012 issue of IEEE Software Linda Rising writes on the role of sterotype and collaboration in teams and explains that i t was only late in here career that she came to the realization that the "people side" of software development is both really important and really hard.

This is an important point, as it is quite easy to think that it's easy to ignore people in a project while you have more important things to work on, such as code, and tools. There is an intersection between people and tools; tools like Software Configuration Management systems, Wikis, issue tracking systems (be they software based or index cards on a wall) can improve or detract from the effectiveness of collaboration on your team. But it's easy to get hung up on the tools and not think about the effect of the tools on the really important thing: How the tools help (or hinder) the people on your team from collaborating to deliver business value.

I was fortunate to have had the importantance of the people side of software brought to my attention early in my career when one of my first managers suggested that I read The Psychology of Computer Programming. Over  time I  discovered more of  Jerry Weinberg's books, and all have had a had a great influence on me. A particular favorite of mine is Becoming a Technical Leader: An Organic Problem-Solving Approach.

It seems like, with resources like this around, and a focus on agile software development, it should be easier for developers to understand that people and teams are as important as they are. But acknowledgement of the humans side of software is not universal, even as we're starting to acknowledge parallels between software development and other endeavors such as artistic performance.

Fortunately there is a excellent recent book by Gil Broza, apltly named The Human Side of Agile, that explores the relationship between people, tools, and processes in software development. I posted a review on Techwell.com, but in brief,  this book is a great agile-focused addition to my list of recommended books on how help teams be effective. Reading this book early in your career will give you a good start on understanding an often neglected aspect of software development. Those who understand it already can benefit the guidance the book offers about how to help others understand.

Reading any (or all) of these books will help you understand how to be more effective, and how to help your team be more effective in turn.

Books mentioned in this post