Archive for December 2008
SBWA – Scrum By Walking Around
If you’ve been in the software business long enough, you’ve probably seen just about every methodology. Waterfall, RAD, OOP and Agile, just to name a few, have all been at the forefront of methodology circles, each briefly having its place as ‘the’ methodology, the One Right Way of doing software development. As different as these methods may be, they all have one thing in common: without execution by talented engineers, none are worth the paper they are printed on. Which brings me to the topic of this post. If you’ve settled on one of the agile methodologies and are using scrum to manage your engineering projects, you may encounter more than just a little resistance from engineers when switching to daily stand-ups and burndown charts. Beyond training, there’s one often overlooked practice that can help socialize the idea and practice of scrum inside your team – talking to people.
The daily walkaround that most managers engage in isn’t designed to randomly annoy engineers. Rather, it is one of the most proven methods of management – management by walking around, or MBWA. This simple practice ensures that you and your team members talk face to face, semi-privately at least once a day, partly to get caught up on activities, and partly to socialize new ideas. If the new idea is scrum, you might want to try a variation on MBWA that I call SBWA – Scrum By Walking Around.
The idea is simple. You’ve trained the team, but the daily scrums aren’t going well. People are missing their commitments, and the burndown chart seems to be flaming up like tech stocks in the good old days. Engineers are frustrated, and their frustration is partly directed at you for advocating YAM – Yet Another Methodology. If this is your situation, you need to do a better job of socializing scrum among your team members. There’s no better time to do this than during your daily walkaround.
Try this: plan your walkaround to take place in the hour before the daily scrum. As you visit each engineer, ask them how they feel the new methodology is going, and take lots of mental notes. Then spend a minute reinforcing the key goals of scrum: accountability to commitments, visible progress measures, and short term rigidity combined with long term flexibility. Later, after the scrum is over but before everyone leaves the room, share the concerns that you’ve gathered privately from your walkaround, and get everyone to agree on a plan of action to address the issues. Chances are that there are a few common concerns that everyone has. By getting these out in the open, it signals to the team that you’re responsive to them, and not just another pointy-haired paper-pushing process wonk.
People, Process and Product
Yesterday I had lunch with an old friend and colleague who like me, is between jobs. After talking about the kids and the family, the conversation turned to shop talk, which for my friend and I is the software business. Both of us are experienced managers, in my case having led teams anywhere from 4 to 45 persons, and for my friend, organizations upwards of 200 developers. What emerged from the conversation was our common view that the single most important thing that a manager can do to ensure a successful software product is to hire and train the right people.
Now, this may seem obvious, but there are managers out there who for whatever reason believe that the development process is the most important factor in team and product success. That you can take mediocre talent, insert it into a formal process, and have superior code emerge from the other end. At the risk of starting a flame war between the process-centric and people-centric folks out there, let’s examine the single equation that rules the software industry: People + Process = Product.
If you walk into a development shop and ask about process, chances are you will get a different answer from everyone you speak with. Managers will often fire off a list of “things that we do” and pass it off as process. Engineers on the other hand, tend to chuckle, smirk and give you a more direct answer, usually something like “I look at my list of defects and features and then write code to resolve them”. If asked about the details of the process, you will get as many different answers as there are team members. This is my first point: your process more likely than not, isn’t what you think it is.
Now, go and ask the same development team about people, and I suspect you will hear a different story: Joe is the best algorithm guy I’ve ever worked with. Jane can step up to unfamiliar code, grok it instantly, and fix nasty bugs quickly. Bob writes useful unit tests. This is my second point: the team knows intuitively who does what best, and if pressed, why those roles are critical to the success of the team.
When asked to come in and fix a troubled team, my friend doesn’t inquire directly about the process when interviewing the team. Rather he asks: what’s working around here? Usually there are 3 or 4 things that the team does well, that can and should be used as the basis of a new process. The interviews also tend to give him a sense of who the top talent is, and who the laggards are. This sets the stage for shifting people into the most effective roles, and adjusting the process – in that order. Similarly, when I have been asked to build a team from scratch, process is the last thing I think of. The first thing is hiring and training top talent. Once there is a critical mass of developers (usually at least 4), a funny thing happens. The developers, if they are truly top-notch, will start to self-organize and suggest a process. At this stage, I step in and help the team put some formalism around the process so that we can measure our progress, and the race is on.
To sum it up:
1. Your process is what your engineers actually do, not what you’ve written up on paper.
2. Great engineers deliver great products.
3. Process is a guideline to keep the greatness wheels turning.
4. If a team is underperforming, focus on your people first, then fix the process.
If you’re managing a large organization or a complex set of deliverables, there’s no question that your development process is important – it needs to be scalable, easy to measure, and non-obtrusive. But, as anyone who has watched the 0-14 Detroit Lions lately knows, without talent in all key positions, no amount of process can produce magic and turn a sow’s ear into a software silk purse.
The Truth About Agile
When you work for a company, it’s important to align your goals with the company goals. In software engineering firms, that often means setting a goal to be adept at your coding job while following the company practices and development processes. If one of those processes happens to be agile development, strange things can happen when engineers try to ‘get with the program’ (coding pun intended!) Engineering managers at software companies, read on to learn how to help your team adjust to agile.
I think there’s a good reason why engineers can sometimes have a hard time adjusting to and adopting agile. The truth about agile as applied at software development companies is that it is not a software development process. It is a product management process, fundamentally designed to feed prioritized, must-do requirements to engineering teams. Once an engineering team has these requirements in front of them, individual engineers may find it hard to distinguish life before from life with agile. Someone, a manager or scrum master, asks the engineer to commit to doing some work. If the team is using scrum and doing short 2-week sprints, then engineer gets to give the most tried and true answer in software development: yup, it’ll take about 2 weeks. And then they put their heads down and start coding. Every morning they stand up at the daily scrum and say ‘yup, it’ll take till the end of those two weeks I told you about yesterday and the day before…’. From an engineer’s point of view, this interaction can be indistinguishable from their behavior under older methodologies like waterfall, and therein lies the rub.
For engineers to really commit to agile, they need to be told another truth. The hard truth in the software business is that it is market driven – and thus the real goals of a company from a product perspective are and should be defined and socialized internally by the marketing department. What agile really does for a company is to force marketing – product management, specifically – to constantly engage with engineering at a fine-grained level. Reviewing requirements, crafting stories, building a global, prioritized backlog. In other words, doing real work to ensure that requirements are understood and that new information on customer needs and market direction is properly reflected in the backlog priorities.
To successfully socialize agile within engineering, there are three things a manager must communicate to their team:
1. Priorities change
2. Team and individual commitments do not
3. Our process moves as fast as the market
The good thing about agile is that it is self-reinforcing with respect to these three points. By doing short sprints, changing priorities become an evident norm. Unlike waterfall, where an incoming course change forces developers to drop what they’re doing and work on something new, agile maintains current commitments until the end of the sprint, reinforcing point number two. When a course change comes in in agile, the next planned sprint can immediately reflect this, highlighting point number three.
Agile isn’t hard or easy. But it is different. By communicating clearly to your team about how priorities are reached, holding them and yourself to commitments, and adeptly shifting gears as your customer and market priorities change, you will improve your success with agile and win over even the most process-skeptical engineers on your team.
Agile Governance: Oil and Water?
Agile governance is about as controversial a topic as there is these days in software methodology circles. Here’s a post that I did for AccuRev (my last before exiting the company) that summarizes my take on best practices in this area. Enjoy!
Developing in streams, releasing from streams
Here’s a link to yet another post I did for AccuRev. It’s a critique of some so-called best practices around branching. Eventually every developer will realize that branches are old and dead, so here’s my small contribution to that end.
Whither branches?
Here’s a link to a post I wrote on blog.accurev.com that addresses some of the problems that development teams have with branches, and why I think AccuRev streams are a superior method of managing code configurations.
Men with boxes
A few weeks ago, while walking from the parking lot into the office, I saw something that at the time didn’t fully register. Two middle aged men walking out of the building, holding cardboard boxes loaded with books and papers, picture frames and ethernet cables. The kind of stuff that one keeps at their desk or cube while at work. When I saw the same scene a few days later, it hit me that there were layoffs going on in the office complex where I work.
When my turn came two weeks ago, it struck me as I drove back home at 10 am that it wasn’t the boxes that had caught my attention. It was the look on their faces, faces that said, what will I do now? How will I explain this to my wife? Will the kids understand why Dad doesn’t get up early, shave and shower and go to the office?
Back home, seeing my own face in the mirror, I recognize that look. The market is tough right now, not impenetrable, but tough. But the moment passes, and my next step is clear. Get up every morning, shave and shower, and go to my new workplace – for now, this Mac, at this kitchen table, working my network, with my 3 year old son on the floor next to me playing with trains. It’s his face that motivates me, that moves me to pack up the annoyance of this career interlude into a mental cardboard box and shelve it. After all, as much as I love marketing communications, nothing can beat laying on your belly each morning with a gleeful 3 year old, choo choo chooing the time away.
Technistas 