Category: Management and Leadership

Why I love physical agile boards, part two

I thought of this as I was writing the previous post, but decided that it was important enough that it deserved it’s own discussion.

Another benefit of physical agile boards is that, by their nature, they tend to limit the scope of your planning. To some, this may sound like a bad thing. It is actually one of the most difficult disciplines to maintain in agile development.

One of the things that distinguishes agile development from older development models is that Agile keeps the time horizons close. This is beneficial because the nature of software and systems development is ever changing, and long-term plans are almost always upset by the realities of the industry and of development itself.

Even strong agile teams see opportunities and features that don’t make sense right now, but they know they will want “someday,” The tempting thing in Scrum is to add these into the backlog, so that they aren’t forgotten. In Kanban, they may go into the “not started” column or some other “feature stash” (The Product Owner and I had a secret Trello board called this when I worked on Revel at Adobe). These far-off stories and epics become their own drag on the agile process, slowing down backlog grooming and sprint planning as the backlog becomes less and less manageable and stories get re-added because no one can find anything.

A physical board actually makes it physically difficult to do this kind of faux-waterfall long-term planning. There just isn’t anywhere to put the post-its/cards! The Product Owner may still have their personal feature stash somewhere, but it won’t become a drag on the whole team.

Similarly, the lack of physical space makes it difficult to over-plan the stories that are in front of the team too. When I was doing Scrum as front-line engineering manager, I found it difficult to figure out how many stories we should break down for a sprint in order to not run short. The tendency was always to task out a lot more stories than we needed, just-in-case. The virtual board makes it easy to plan as many stories as you want. In practice, stories have dependencies on each other and if you over-plan, you tend to just write incorrect tasks.

A physical board encourages you to plan just as much as you need, and not much more.

Why I love physical agile boards, part one

After years of exclusively using virtual Scrum and Kanban boards, I am using physical boards again. In the process of adapting, I’m rediscovering many great things about using a physical board. One benefit of a physical board that I didn’t expect is that your stories and tasks tend to be less formal.

Last week there were two stories on two different team’s boards that made me laugh. One was:

20130825-194731.jpg

The other (which I didn’t get a picture of) was “do the thing with the thing“.

A good agile coach would point out that both of these were under-specified and poorly written. A better agile coach would point out that as long as the whole team understood what they meant and there was an agreed-upon definition of done, then the wording doesn’t really matter that much and it is fine for the squad to have an occasional story like that.

Neither of these would have ever appeared on a virtual board. By being on the computer/net, the virtual board has two features that the physical board does not.

One is longevity. “Do the thing with the thing” is fine if it is a story under discussion every morning at standup, and tossed in the trash when it is done. “Do the thing with the thing” would be a cryptic mind-f*ck a few years or even weeks later if someone was reviewing old stories.

Now this longevity element is something that I used to like with the virtual boards, having the history and being able to see how things developed and where they came from. In reality, you don’t really ever have time for that and instead it becomes another digital barnacle that isn’t really that useful.

Another property of a digital board is transparency. Theoretically, anyone in the company can see it. This again, is both a positive and a negative thing.

Having a board that anyone can see means that what your team is doing, will do and have done is available to anyone. Status reports are (theoretically) not necessary. If anyone asks what you’re working on, you can tell him or her to go look at Trello/Pivotal/Jira/etc and bug you if they have any questions.

With a physical board though, they need to come to the team and look at the wall. This means that any misunderstandings can be cleared immediately, and communication is actually improved by, you know, people speaking to each other.

When you are creating stories, tasks and notes on a virtual board, you are writing for an indeterminate audience. You are writing for yourself and your co-workers, but you never know who else will be reading it. If something you write has to make sense to anyone, ever, you will be a lot more guarded in what you say. You will be wary of not only how the story is perceived, but also, how you as the author are perceived. It is the difference between the conversation you have with a coworker over a beer and the item that you post to a blog or twitter.

That consciousness of the potential audience takes all the spontaneity and fun out. The formality makes stand-ups and planning take longer as well.

If you work on a co-located team and are using a virtual board for your agile practice, try going old-school for a while. I’m betting that your stand-ups and planning will go a bit smoother if you know that the stories and tasks that you write are for your team’s eyes-only.

Whatever you do, don’t forget to do the thing with the thing, and while you are at it, unf*ck everything.

[see part two: where I discuss how physical boards help you keep a manageable time horizon to your planning]

On Microsoft’s new structure

http://www.bonkersworld.net/organizational-charts/
http://www.bonkersworld.net/organizational-charts/

Microsoft finally unveiled the new much-rumored organizational plan. Glad to see Microsoft moving audaciously. This is long overdue.

However, knowing that organization, I don’t know if there is much chance that it will be successful. The whole organization has been set up to compete with each other for decades. This kind of cultural change is probably beyond what is possible at this point. The battle lines are too well established, the rivalries too set in stone.

The culture of Microsoft has always been one of intense competition. Successful individuals and managers rise more on their ability to outshine their peers rather than cooperate. A new high-level alignment or a single memo will not change that. If Microsoft really wants to be nimble and more collaborative, they need to clear house.

Furthermore, organizing engineering as massive silos that are parallel to the other massive silos representing other business functions is exactly the wrong way to do this. Every new effort will require coordination between massive groups with conflicting priorities, politics and agendas. Everything will be harder. The company itself is so massive that having responsibility for the success meet at the tops of these tall functional mountains will not be sufficient to make these efforts work. The people with responsibility will be too far away from the details to be effective. Layers upon layers of management (each with their own goals, agendas and success metrics) will need to be navigated to get any level of cooperation.

It’s going to be a tough few years for the employees at the company. For the front-line engineers, their day-to-day work will probably not change much, but at the higher levels, there is going to be tremendous pain as the new structure and corresponding power battles work themselves out. In the end, I expect very little will change on the inside, or the outside.

I’d be delighted to see Microsoft prove me wrong.

Moving to scrum: breakin’ the law

Well, part of the whole idea is that scrum isn’t a hard-and-fast set of rules right? I had some meetings at another office last week which necessitated moving out our first sprint review and retrospective a couple days. So if one of the guiding principals of scrum (and agile in general) is that the dates don’t change, everything else does, that got blown right out of the gate.

Some new stories came up as part of the sprint wrap-up which means that we’ll need to do a new planning poker session. Also, some other things came up which mean that there is a bit of housekeeping to do before we start the second sprint. We’re now in some uncharted zone between two sprints while the product manager and scrum master do some cleanup while the scrum teams do some off-book work for a couple days. Yeah, not ideal, but we’re trying to get it back on track. This sprint was going to be a throw-away anyway as it involved a lot of transition and getting used to the framework.

The retrospective brought up some really good issues and some innovative suggestions from the team on how to handle them. If the suggestions work out, I’ll post them here eventually.

There are still some folks unclear on what we expect to gain by transitioning to a new development process, but most of the team is embracing it as a good experiment and chance to try something new. For the most part, everyone seems to have an open mind and that definitely makes a huge difference as we all try to figure this out together. It hasn’t been the smoothest transition, but so far so good, I think. We’re definitely not as productive as we were before (so far). However, I think that the discipline provided by the product backlog means that we are actually getting the most important things done first. That makes a huge difference.

Converting from agile-mumble to Scrum: the introduction

I’ve been a convert to Agile for almost a decade now. I was first exposed to it when I was working at a start-up called Bootleg Networks as a Development Lead (don’t bother looking it up, it is long lost to time). I’d just come from six years at Microsoft where Waterfall was the only methodology and it was followed religiously. I’d seen all the worst aspects of Waterfall and seen nearly none of the best, but I wasn’t up on any other methodology besides Ad-hoc (also known as “play it by ear”). We’d hired Carmine Mangione as our software architect and he came in spouting all this stuff about “Agile” and “XP.” While I was definitely ready to try a different style of development, it all sounded a bit unstructured to me. Carmine convinced me to try eXtreme Programming, promising that if it didn’t work, we’d drop it. We bought a stack of Kent Beck’s book for the team and jumped into it. I went from Development Lead to XP Coach and quickly became a convert.

We achieved a ton of stuff using XP at Bootleg very quickly with a relatively small team. That short stint really changed my mind on how professional software development could be done. Ever since then, I have found ways to incorporate as many aspects of agile methodologies into any place I’ve worked.

I ended up back at Microsoft a couple years later. The situation there had changed quite a bit. While most of the company was still doing waterfall, more developers were aware of Agile and were curious about it (even if their managers weren’t). I took on a risky new project. It was fixing an ancient set of code written originally by Microsoft, but completely eroded over the years by a series of contractors. It was a mess: full of bugs. Customers didn’t like it. Rather than try to fix it, I convinced them to let me and a small team rewrite it from scratch to clean it up and get the new functionality needed. Program Management was skeptical, Quality Engineering was dead-set against it. I put my neck out and promised that we’d bring it in on-time with a high-level of quality that would be instantly verifiable with a battery of developer-written unit tests. We got some initial buy in and we went to work. We followed as much of XP as we could with an undersized (4 person) development team. Needless to say, we got it done and it shipped as part of WinCE 5.0.

I left Microsoft to join Adobe and was really happy to see that Agile was not only acknowledged, but embraced across many groups in the company. There were many different flavors being used, including several custom ones. Scrum was fairly common though.

I was certainly aware of Scrum, but didn’t have too high an opinion of it. Everything I’d read and heard about it made it seem like it had nearly no process or structure. Looking at how different teams “followed” scrum practices, it seemed like it was just an excuse for Cowboy Coding with a tiny amount of coordination involved. It seemed like a parody of Agile to me at first.

At Adobe, I was lucky enough to be able to build a completely new team. For various reasons, the team ended up being split between two different offices. While I wanted us to follow an Agile methodology, after a lot of research, I couldn’t identify one that would really work for us wholesale. Instead, I took the pieces that made sense and incorporated them as I could. We ended up with a unique process that subsumed bits of Rational (short sprints at first, longer sprints in the middle and short sprints again at the end; co-located functional teams), XP (test-driven development, occasional paired programming, be able to deliver at the end of each milestone, constant refactoring and narrow focus) and Scrum (demo-able at end of each sprint). That was the goal process. Of course, we didn’t always get there. We were pretty open and made a lot of changes along the way to incorporate new best practices and dump the parts that didn’t work. This evolving process worked fairly well and we have had three successful product cycles over several years using it.

For all the good of our existing cobbled-together development framework, we were always finding the seams, the edges that didn’t quite meet. There were other issues too. Having co-located functional teams meant that each team had good velocity, but it also meant that cross-site communication was always a problem and it made collaboration difficult as well. The team was getting too silo’d in my opinion. I wanted to really mix things up for our next cycle and try something totally new.

Over time, I’d gotten over my initial knee-jerk reaction to Scrum as I encountered more teams using it in a more deliberate and successful way. One weakness I still saw was the difficulty of using Scrum in non-co-located teams, but I met teams that came up with ways to manage this.

I decided that we would try Scrum for our next cycle. If it worked for us we would continue to use it for future cycles. If it didn’t, we would incorporate whatever worked for us back into our old process. Luckily, Adobe has a full-time Scrum trainer in the company. We did our scrum training a couple weeks ago, and we start our first Sprint tomorrow.

I’ve decided to document this on my blog for a few reasons:

  • It is something about Software Engineering that I can write about without fear of divulging corporate secrets
  • It might be interesting for other folks in similar circumstances
  • It is too long to tweet 🙂

My plan is to document our transition as much as I think might be interesting to others. Our situation is a little different from most since we are transitioning from a different Agile process to Scrum instead of from a non-Agile process. My team is also somewhat unusual since most of our clients are internal to the company who each use a different methodology (most Scrum, but some waterfall and some other Agile), but we also deliver our technology straight to Adobe’s customers on both long and short cycles. So we have a lot of impedance matches to account for. Some things may need to wait until the cycle is over for fear of disclosing too much, but by focusing on the process, I hope to be pretty open.

I’m not going to go too far into the mechanics of Scrum here since there are a zillion better places for that and because I’m still learning it myself. If I use a term you aren’t aware of and you can’t find a good answer on Google, ask me in the comments and I’ll try to answer it for you.

A bit on the details: My team doesn’t have a “Product Manager,” so I will be taking on the role of Product Owner even though I am the Engineering Manager. I’m not planning to act as a Scrum Master, that role will be taken by the QE manager of the team. If I have some free cycles I can use for development, I will act as a Scrum Team member, but I will not participate in Planning Poker as an estimator. We will have two scrum teams, each team incorporating developers and QEs from both of our sites. We’re going to do short sprints so that we can make changes quickly to our process.

I hope to create a little series here if I have time to keep it up to date.

Stay tuned.

Joel Spolsky’s love letter to program management

Joel Spolsky wrote a love letter to program management on his blog. For the most part, it is a pretty reasoned and reasonable description of what a “good” program manager at Microsoft (and Fog Creek) is like. In my career at Microsoft, about 25% of the program managers fit that bill. The problem was that they had too many conflicting roles and required skillsets to be effective. At Microsoft, Program Managers are not only responsible to be user advocates, they are also responsible for functional specifications, user interfaces and schedules. A single person can’t be a user representative, a UI designer/interaction specialist, and a project manager. Combining them into a single role worked for Microsoft initially, but in the modern world each of these roles are full disciplines of their own.

Joel claims that PMs are partners with development and that developers have the upper hand over PMs because they write the code. This might have been true of Microsoft in Joel’s (and my) time, but as MS switched from being an engineering-driven company since Ballmer took over to a program management-driven one, it isn’t true any more. PMs took the upper hand because they had far too much control over the final look and feel of the product and could essentially name themselves the final arbiters. Development and QE were isolated from the customers. PMs dictated the features; meaningless meetings and committees abounded and the products suffered (every MS product in the last 8 years for example).

How to be a program manager – Joel on Software

Writing a functional specification is at the very heart of agile development, because it lets you iterate rapidly over many possible designs before you write code. Compared to code, a written spec is trivial to change. The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed.

This claim is just wrong, or rather, doing this in the large scale is just wrong. I’ve worked under that system at Microsoft for years and I never saw it be very successful in practice. Maybe for a small part of a product, or a small iteration in a larger cycle it might work; but at the product level it is nearly always a bust. Why? Because you will not anticipate everything in your functional specs. Ever. A competing product will be released with better features. Flange A will not fit Bracket B. User testing will hand you your hat. Beta testers will tell you that it wasn’t really what they needed. And then you are back to the drawing board. Except you are two-thirds of the way through the cycle because you spent a huge amount of time iterating over the spec and then building to that spec. Now everything is screwed up, but QE needs to start testing to the spec RIGHT NOW. So what do you do? You hack. The spec goes out the window and development codes for dear life while program management throws out ideas and changes like pieces of spaghetti against the wall. At the end of the cycle you have a tarball mess of code with incongrous, hacked, features that came crashing onto the deck of the carrier and just caught the last wire. Watefall development is resistant to change, agile development embraces it. Change happens faster in our industry every year, why lock your developers into software methodologies from the 70s?

Is there a role for Program Management? Absolutely. Not for the Microsoft-style Program Manager, but certainly for the jobs that the Microsoft Program Manager has. UI design and look and feel is best managed by professional user interaction specialists working with a project manager and development. The project manager can also be the primary representative of the client, but not the sole conduit. One of the primary jobs of QE is to be a user representative. Isolating development from the users just means that they don’t understand why they are doing what they do. Isolating QE from the users mean that they can’t represent a user of a product in their testing. The Program Manager can also work with development and QE to manage the schedule.

My experience with great program mangers post-Microsoft are folks that coordinate across all the functional groups to make sure that development has what they need, QE understands the user, experience design is delivering on time and all the clients are feeling well represented. In this view, the program manager acts as a lynchpin connecting development, QE and XD to their customers. Do they set the schedule? no. Do they write the specs? Maybe (in a non-agile team, working with the other groups). Is that less fun for the program manager? Maybe, but it produces much better products in my experience.

Did a mock technical interview event tonight at UW (more tips for college CS students looking for a job)

It was actually a lot of fun. Usually when you are doing a real interview, you can’t really take the time or energy to explain to the candidate what they did wrong and how they could improve. Also, I was very impressed with the quality of the candidates. At Microsoft, I interviewed a lot of college grads in the last few years from schools like Berkeley, Stanford, Princeton and other CS powerhouses. Most of those students were pretty weak compared to the students I talked to tonight.

There were a couple pieces of advice I offered to all three candidates. Most of this is only relevant for recent college grads, but some may apply to others as well.

  • Learn more C++. A lot of CS schools like teaching Java. It is fairly good for teaching some of the fundamentals of Computer Science. However, it is still not very popular in the software industry outside of server software. If you are looking to be a developer at a software company, you will almost certainly be writing in C++ and you will have an edge if you can write good C++ in your interview.
  • Practice programming problems. Most software companies that I know (including Adobe, Microsoft, Google and Amazon) do whiteboard-style interviews. You will be given a programming problem and will be expected to write code to solve it. You may also be asked a logic problem. There are many web pages that have actual technical interview questions, you should use them to practice with.
  • Wear appropriate clothing. Unless you are doing software development as part of a consulting company or at a bank or insurance company or something, developers wear jeans. Wear nice jeans, without holes. Don’t wear gym shoes (even cool, expensive ones). Wear a nice shirt. Do not wear a tie or jacket: you will be uncomfortable and will feel out of place. You want to look nice, but comfortable.
  • Be honest about your abilities. Don’t lie about what you know. We’ll figure you out pretty fast.
  • You are not a 9/10 in C++. This is one of my pet peeves and I’ve written about it before.

Now about your resume

  • It should fit on one page. Unless you were working in the industry for years and years, you should be able to fit all your info on one page.
  • Your hobbies and outside interests are not relevant. It is resume filler and will have no bearing on if you get an interview or not.
  • Your job experience outside of the industry isn’t important unless it is relevant to the position you are seeking. If you have relevant or significant full-time job experience (ie: not retail or food service), you should list it. If you were a manager in a non-tech business, that might be relevant if you are looking for a management position, but not an individual contributor position.
  • Put the most important stuff first. People read top to bottom. If the top of your resume isn’t compelling, people reading it won’t make it to the bottom. When I was younger, I used to have my education at the top of my resume, because I didn’t have as much experience. Now my experience is at the top since I’ve been out of school for 15 years. When I look at college grad’s resumes, I look at the school (do I know it?), then I look at their job experience (have they programmed professionally?), then I look at their skill sets (do they know C++?). Unless one of those things stands out to me, I won’t bother looking at the rest.
  • List classes taken which relate to the position you are applying for. I don’t need to know every class you took in college, but if I’m hiring a graphics programmer and you took 3 undergrad classes and a graduate seminar in computer graphics, I want to know.
  • Think about keywords. Most resumes come in electronically now, via a company’s website. There they go into a database. When a position is opened, recruiting will do a search on their database looking for keywords: C++, graphics, windows, etc… Make sure that your resume will be found in those searches.
  • Target your resume to the position you are interviewing for. This could be a lot of work, but it is worth it. You may not need to change everything, but at least change your objective. If you are applying for a lot of jobs, you may want to make different versions of your resume for different classes of positions. I have three different versions of my resume which emphasize different skillsets depending on what kind of job I am applying for.
  • Don’t write a wishy-washy objective statement. I’m kinda over the whole “Objectives” thing on a resume. Obviously, you want a job. Everyone wants “a challenging position with an interesting company, utilizing their skills and allowing growth potential.” Yawn. This is the one place where it really is important to tailor your resume to the position you are applying for. Especially, if you are moving from one area (QE) to another (Development).
  • Use good ideas from other resumes. The Microsoft Word resume templates are not your friend. Everyone knows them now. Luckily, you kids have this thing called the interwebnet which allows you to find a zillion resumes and look at the best ideas from each. Everytime I see a good idea from a resume (a better way of listing experience, a more consise way to describe skills), I see if it is something that can help make my resume better. The actual graphic design and layout of my resume grew over years, incorporating ideas from a dozen other resumes. (Please do not directly steal the design of my resume (I’ll make sure that you’ll never work in this town again), but feel free to incorporate some of the ideas for your own).
  • Have someone you know, someone who actually knows how to write well, go over your resume. Engineers are not known for their command of grammar, punctuation or command of the English language. You only need to look at this post to see what I mean.

If other people have more suggestions, I’d love to hear them.