Steve Berczuk

Jurgen Appelo’s useful and fun-to-read book Managing for Happiness: Games, Tools, and Practices to Motivate Any Team gives you concrete tools to identify ways to help your team be happier and to create environments where people can thrive and be more productive. Despite the word managing being in the title, the book is a beneficial read for anyone.

Gil Broza's book The Agile Mind-Set: Making Agile Processes Work speaks to the challenges faced by people who focus on "doing agile" rather than "being agile." Rote execution of methods can only get you so far, and Broza gives insights into how you move beyond practicing agile by habit into living it.

Agile methods are one way to use iterations and frequent feedback to manage risk. Getting feedback early so that you can make corrections or change expectations isn’t a new idea, but implementing a process that can give you both this feedback and the tools you need to make corrections is difficult for a number of reasons.

I recently wrote a short article on on StickyMinds.com about automation. After it was published I came across another related post by Jim Coplien which makes the point that automation should come after you have figured out your process.

One of the more difficult challenges people and teams have in the face of deadline pressure is taking time to consider how to approach a problem rather than just diving in with a solution approach that you know will work.

By understanding the context in which their existing practices were meant to work, teams new to agile can more easily decide which of those practices still make sense and which are simply security blankets.

One of the great things about being a parent is that you have an excuse to re-read some classic books. My five year old and I have been reading The Little Prince, and the story of the Lamp Lighter reminded of a common problem teams have with organizational inertia when trying to transition to agile software development.

It's almost a matter of dogma that, for agile teams, low tech project tracking tools and artifacts are superior to electronic ones. The usual reason you might hear for preferring a physical task board to an electronic issue system are are that a physical task board is more visible and encourages communication and collaboration. I appreciate this, and have seen it, but I've also seen teams do well with issue tracking systems. From time to time I see a discussion of this "physical versus electronic  tracking" issue and I find myself frustrated by it, but not sure why.

I've worked with Scrum for a while, having gotten my CSM certification in 2005, and I've spent time both before and after that trying to learn what I could about Scrum, agile, and Lean, both in the context of software and out side of it. After absorbing bits of information on Kanban informally, I decided that to was time to read a book on it. I read David Anderson's book Kanban: Successful Evolutionary Change for Your Technology Business.

People often ask, "Can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is, "Can my type of project really be structured in an incremental way?"

A few weeks ago I had the opportunity to give a virtual talk at a product launch for an SCM Tool vendor. The theme of the talk was basic branching strategies, and preparing for the talk led me to reflect on what Brad and I wrote in the SCM Patterns Book. This post is based on those thoughts.

Words and definitions help with communication. And it's hard to come up with an unambiguous word. But try hard to use words as they are defined in your context. That will help you to communicate, set expectations, and maybe even be more agile.

Agile software development always felt intuitive to me. Developing software incrementally, in close collaboration with the customer is the obvious way to deal with the uncertainty inherent in both software requirements and implementation. The technical practices of automating necessary but time consuming tests, and deploying, early and often are the obvious ways to give an team the ability to evaluate the  functionality you have and to to decide if the software works as expected. And it's also important to decide if what you built still makes sense given the current environment.

Continuing the conversation from last week, Andy Singleton followed up on my post on being done with this post. Which is good as this is one of those questions that sounds simple in theory, but in practice contains some subtlety.

Agile New England (which used to be called the New England Agile Bazaar, and which was started by Ken Schwaber) , has this wonderful activity before the main event each month: they host Agile 101 sessions, where people who know something about agile lead a short (30 minutes) small (about 10 people) class on agile basics for those who want to learn more about some aspect of agile. 

There was an article in the Boston Globe recently by Scott Kirshner: Staying Competitive in the Workplace that emphasized the importance of keeping your skills up to date.

Steve Berczuk was recently was interviewed for an article  on SCM and Tools. Updating tools and processes key to overcoming SCM challenges is brief and makes some good points about the relative value of tools compared to understanding what you are trying to accomplish with your process.

I had the opportunity to get a review copy of The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries.

In the past few months I've heard a couple of stories about (in effect) the disadvantages of experience when it comes to innovation and productivity. A Story on WBUR on July 5, 2011
discussed how venture capitalists tend to favor young entrepreneurs, as, having never learned the wrong things in business, they don't know what's possible or impossible. In one quote, a VC said:

Branching can be an effective solution for managing change, enabling parallel development and improved productivity. But, working on a branch is a distraction and can decrease agility, productivity, and code robustness. Learn when the value of working on a branch outweighs the cost.

Agile development practices at their core, have a common theme of making better use of the time spent developing software. This starts at the project level and continues down to the developer day-to-day-activities. Consider an agile iteration. The team starts the iteration with a clear sense of the priorities for the sprint, and pretty good understanding of the project scope. Having estimated and committed to getting the work done, the team also has a sense that the goal is attainable. The team members then collaborate to get the work done as a team.

I was thinking about the relative value to a team of a developer with specific skills (say UI development) versus adding someone who was more of an end-to-end developer. Two stories about medical practice that provided some insight into the question.

Habits and routines are useful because they free you to focus on the important tasks.  Rituals and processes take a somewhat irrelevant decisions out of your hands, and conventions make it easier for others to understand code and other artifacts.  And when you are starting a new approach to work, following the rules by rote can help you understand the method.

In the book Better: A Surgeon's Notes on Performance, by Atul Gawande, a discussion of how hand washing—a simple technique that is vital to infection control—brought to mind how the challenges teams have being agile often center on the challenges of having teams begin to apply basic practices, without customization.

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example.

I recently wrote a couple of articles that might be of interest to those who read this Blogs.

On Sticky Minds.com, (a TechWell community) I wrote about unit testing, and how to overcome the inertia that stops people from testing in The Value of Really Dumb Tests

If you didn't already know that the key to reliably deploy quality software is to take a cross-functional, full-lifecycle approach, Jez Humble and David Farley's book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" will help you to understand.

Teams transitioning to agile struggle with understanding the role of QA and testing. Much of what you read about agile focuses developer testing.  Every project I've worked on which had good QA people had a much higher velocity, and higher quality. And there are limits to what developer Unit Testing can test.

You have probably come across a situation like this: It's close to a release deadline. The QA team is testing. Developers as testing and fixing problems, and everyone is focused on getting the best product they can out the door on time. During this time, you may notice that someone on the QA team, while working late has found an interesting problem. Unfortunately, your team found and fixed the problem hours before.

Agile methods have some sort of daily all-team checkpoint meeting as part of  the process. The idea behind the Daily Scrum (Scrum) or Daily Standup (XP) is good:  replace status meetings (or someone walking around asking about status) with one short daily meeting where everyone has a chance to communicate about what they are doing and what they need help with. 

This two-part article explores branching strategies—development tactics that allow teams to work concurrently on different features and maintain the relationship between them. In part one, Steve Berczuk explains what branches are, common types of them, and the tradeoffs between branching styles.

Checklists help teams make better decisions by making it easier to distribute decision making. A team of empowered cross functional people, working together to decide how to get work done sounds a lot like the model of an agile team.

 Jim Coplien's recent book, Lean Architecture: for Agile Software Development, explains how agile principles and architecture are complimentary, and how, with everyone working collaboratively, a good, lightweight architectural framework can help enable agility, rather than being a barrier to it.  With his usual iconoclastic style, Coplien dispels the myth that agile doesn't need architecture.

Johanna Rothman recently wrote, commenting on Joshua Kerievsky's proposed definition of done. Both posts are worth a read, if for no other reason than to better understand why we have such a difficult time defining what "done" is, and why defining "done" is one of the major challenges for teams  trying to adopt agile practices.

x

One of the things teams adopting agile struggle with is deciding how much to define a plan before you start executing. Have a plan that's too well developed and you end up risking that your team may not be responsive enough to change. Too little of a plan and you may end up changing course excessively, and have no way to measure your progress towards any sort of deliverable.

I recently read Craig Walls' book Modular Java: Creating Flexible Applications with Osgi and Spring (Pragmatic Programmers). This book is a very detailed tutorial that walks you through setting up an application using OSGI and Spring with the help of Maven as a build tool.

Being agile is a means to an end; your goal is to develop better software more effectively, not to be able to wear a "We are Agile" badge. If you're considering adopting agile, you are probably doing do because your current approach isn't getting you where you need to be so it's worth giving the 'by the book' technique a shot before you try to adapt an agile method to your circumstances.

Planning aoker, an estimating method popular with tgile teams can address some of these issues. Briefly, planning poker involves getting the developers on a team together to estimate stories using a deck of cards that have numbers that represent units of work.

One of the things that makes agile work well is a daily sense of progress that can be reflected in, for example,  a burn-down chart.  For burn-down charts to be meaningful, the estimate of amount of work remaining in a sprint need to be accurate. Re-estimating work remaining in a task is helpful,  but the best measure of progress is the binary "done/not done" state of the items in your backlog.

Burn down charts help agile development teams track sprint and release progress. The basic idea of a burn down chart is that the team starts with estimates for all of the tasks in the sprint, and then on daily (or more frequent) basis re-estimates the amount of work remaining.

The previous two January Agile SCM columns made some short-term (and a few longer-term) predictions about the impact of current trends on the practice of Agile development as it pertains to SCM. This January we revisit those predictions to see where we were right, where we were wrong, and recalibrate our ideas of what's in store for Agile SCM in 2007-2008.

We thought 2005 was a pretty gosh darn great year for Agile Software Development and Software Configuration Management alike. We wanted to share what we feel are some of the timeless classics that we have most looked to throughout the year, as well as the new books in the last year that we have been most impressed with.

The authors examine the fundamental truths about project and requirements changes: What can we control? What is beyond our control? What are some of the common perils and pitfalls of change-control and iterative development? We discuss how to avoid many of these common pitfalls without creating new ones along the way, and provide a wealth of resources for first-timers to iterative development.

We have been indulging in a mixture of wishful thinking and crystal ball gazing to consider what the future holds for Agile CM. To misquote Malvolio, "Some things are born great, some things achieve greatness, and some have greatness thrust upon them." Rather than try to make grand predictions for 5 or 10 years down the road, we're mostly limiting ourselves to the next 1-3 years (except where noted of course).

Traceability! Some crave it. others cringe at the very mention of it. For hardcore configuration managers and requirements and systems engineers, it is a fundamental commandment of “responsible” software development. For many hardcore agilists and other developers, the very word evokes a strong “gag” reflex, along with feelings of pain and frustration. Traceability requires work and discipline! So how does traceability add value to our business and how can we make it easier?