When Agile Becomes Fragile

In my last post, I didn't addressed the issue of agile planning boiling down to "only planning 2-4 weeks ahead." Based on what I've seen, this is still a common misconception in game development. I've encountered skepticism about agile from managers at three different game companies who had seen agile projects go off the rails. One manager dubbed agile development, "fragile development." From what I understood, they attributed the failures to poor planning that focused on the short term.

Every project needs to find a balance between anticipation and adaptation. Finding a balance for a given project is part of being agile. Unfortunately, I think practices like daily stand ups and iteration planning are much better understood than longer-term planning practices like release planning. One game studio I know of was spending a lot of time rewriting the game engine for a franchise, and I wondered how that fit into their release plan, e.g., how would they fit that work in before full production needed to begin? I was told they didn't have a release plan. I think that's a recipe for disaster. Mike Cohn has explained the importance of release planning pretty clearly:

"A release plan helps a team avoid finishing a series of sprints and feeling that, while they always worked on the highest priority items, the collection of work completed does not add up to a satisfying whole."

I think this planning is especially important in game development with its different phases: concept, pre-production, production, and post-production.

I also surmise that projects run into problems with prioritization, risk assessment, and estimating costs, e.g., cost of delay. I think new agile adopters understand the practices for teams and the role of scrum masters much better than they do the role of the product owner. It's not always clear who should fulfill this role: design or production. I suspect this role isn't often filled well (or at all.).

Agile isn't synonymous with Scrum or time-boxed planning practices. I think that game development poses special challenges and tools in addition those used in Scrum are needed. I want to address this in "To Timebox or Not to Timebox (Part II)."

To Timebox or Not to Timebox (Part I)

I was never particularly interested in project management or scheduling until I read the book Agile Estimating & Planning by Mike Cohn five years ago. I'd been working in software for 20 years and scheduling seemed like a dull and tedious exercise at best. At its worst, scheduling seemed like a black art full of lies, falsehoods, and deceptions.

As a programmer interested in learning about agile, I started reading books focused on the technical side of agile software development. Most of the agile programming and software design practices made sense to me. As far as I could tell, the agile approach scheduling seemed to boil down to "only plan 2-4 weeks ahead." This seemed neither practical nor sensible. I picked up Agile Estimating & Planning to find out what the deal was. The answers I discovered were much more interesting than I expected and eventually motivated me to eventually change careers from programming to project management.

The first idea in Agile Estimating & Planning that rocked my world was planning using iterations (now more popularly  known as sprints). It was my first exposure to timebox scheduling. I was used to working with milestones in software development. It was often unclear whether milestones were defined by "date" or by a "state." Dates were set for milestones, but there was also the expectation that certain goals would be achieved. The dates were usually more clearly defined than the goals and milestones were usually months apart.
 
Timeboxed iterations immediately struck me as a great idea after seeing a lot of problems planning and scheduling programming work over the years:

• The time horizons for development could be long and work often involved a lot of uncertainty, failure, and iteration. Planning and scheduling was often done irregularly, if it all, after the initial phase of the project when the least was known and understood.
• Scheduling often took the form of getting precise estimates for a long, linear sequence of tasks. Gantt charts showing a single line tasks for individuals, each task starting on a specific day and ending on a specific day, were rarely a reflection of reality.

The timeboxed method of planning described in Agile Estimating & Planning made intuitive sense to me as an software engineer.I believe that there are many advantages:

• Regular frequency of planning. Planning and scheduling needs to be an on-going activity throughout a project. Requirements and priorities change and a lot of information is learned as development progresses. I've had problems when planning was irregular: 1) too long a period and plans and schedules are far out-of-date and people are no longer working to a plan; 2) it's annoying as a programmer when goals and priorities change out-of-the-blue on a frequent basis. There are costs associated with planning and switching tasks. They need to be considered and managed.
• A comprehensible time horizon for planning. When I'm thinking about time and programming work, I can wrap my head around a few weeks. Much longer than a month and I start waving my hands. It becomes easy to procrastinate. I've rarely seen a detailed task plan survive and be useful for more than a month.
• A focus on deliverables and not activities. The focus on planning for iterations is the delivery of useful functionality fulfilling a clearly defined definition of "done." It's not about completing activities. Ultimately, results are what matters. The activities required to meet goals are more uncertain and change more frequently than the goals themselves. I find focusing on completion of activities leads to the problem of  Parkinson's Law: Work expands so as to fill the time available for its completion..
• Commitment-driven planning. I'm a big fan of making and keeping commitments in work. [I could write a whole post about it.]  I want to be able to commit to results that are achievable. Given a fixed time horizon I can comprehend and a pile of estimated work, I can make judgment about "too much" or "too little."

As anyone who has seen my schedule diagrams, I have a much easier time picturing and working with schedules visually by using timeboxes: fitting work items of various and somewhat variable size into buckets. This has been a natural fit for how I've seen the activity of programming. I'm not usually proceeding along a linear series of steps that start on day X and end on day Y.

Other people have written about the virtues of timeboxing. As well as planning software projects, timeboxing has also been useful managing my own time using the Pomodoro Technique.

At first I thought timeboxing was "it," a general purpose solution for all of the planning and scheduling challenges I could care about. That lasted until I had to schedule game art and asset production. Next post I'll write about the limitations of timeboxing when I find a need to use a different approach.

Communication, Complexity, and Complication

I had a phone interview with a company today for a project management position. I was told it was a "phone screen." I'm glad I did it because I need the experience interviewing for project manager positions. The call turned out to be more of a full interview and an unpleasant one for a number of reasons.

Two questions among the battery of questions the interviewer asked (with no enthusiasm and pretty clearly reading from a standard form) were roughly

1. What are skills of good communicators? 
2. Describe the most complex problem you've solved in one of your jobs and give specific examples of what you did to solve the problem.

Like the subject of narrative in my last post, I can think of hundreds of things to say about good communication skills. It doesn't help that I just read Management 3.0 and my mind is full of new ideas. I could say so much, I'm kind of thrown for a loop when asked such a general question in such a context.

I get thrown by questions like these when they aren't part of a conversation, and  I can have a hard time with tests. In retrospect, I know I should tell stories that sell my abilities when asked these kinds of questions. Looking at the different types of communicators, I'm definitely not a salesman. However, I believe 'Influencing' is among my capabilities nonetheless.

What I was really thinking was the question was asked was, "Why are you asking this question?" Ironically, I need to work on my communication skills when interviewing. What I heard during the conversation was from the very start was, "I don't want to be interviewing you. I personally don't care about any of your answers." In retrospect,  that's what I heard, and I wish I would have reflected back (in a diplomatic fashion) what I heard instead of continue through an increasing painful interview process.

I've heard the second question many times in software engineering interviews. Now I need to be prepared to answer it in project management interviews. I wasn't prepared for this phone interview. Trying to answer it on the fly, I was flummoxed right off the bat because I was wondering what qualified as a "complex problem." This has tripped me up in the past. The word complex is used in a lot of different ways:

1. Complicated: difficult to analyze or understand

This is how I have usually interpreted "complex" in technical interviews, which are usually trying to determine how smart you are. By default, I think of technical smarts as mostly defined by your ability to solve technical problems requiring complicated math, complicated algorithms, or clever hacking skill.

I found a lot of my hard science coursework in engineering school hard to understand. In comparison to engineering school, the majority of the programming I've done hasn't been that hard to analyze or understand with several notable exceptions. In comparison to engineering school and some programming problems, I don't think of the problems I've solved in project management as complicated.

2. Challenging: requiring full use of one's ability or resources

A lot of the work I've done as a project manager and a software engineer has been challenging. I love being challenged and there lots of different types of challenges. In retrospect, I think this is how I should have interpreted the question.

3. Complex: 1. A whole composed of interconnected or interwoven parts; 2. somewhat predictable (but with many surprises) [the second is the definition applicable for describing complex systems]

I don't think complicated algorithms, complicated math used in games, and clever hacking is complex using these definitions. However, the large software systems I've worked on, and in many cases designed, have had a lot of interconnected parts. There was a lot to manage and organize. I think you could argue that that large software systems are also complex, adaptive systems.

Except for the rare trivial problem, managing people and projects is complex using either definition. How do I deal with complexity in project management?  I use the whole set of practices and tools I've been developing over the last several years and I'm continuing to develop. (Which I had described earlier in the phone conversation).

Well, I told the company I was not interested, but it was good practice. I'll be better prepared for the next test. I like storytelling so I'll come up with some good stories to tell when given a wide open opportunity to sell myself. A former studio GM showed me the value of being a good storyteller.

Complexity at the Workplace

Reading Management 3.0 is a departure for me. I've never been enthused by the thought of being a manager or been interested reading books about management. Despite my reservations, I picked it up and started reading it because it's a Mike Cohn series book, has a forward by Robert Martin, and explicitly mentions "agile leadership" in the subtitle. When I saw that it had a section explaining complexity theory, it jumped to the top of my reading queue.
 
I've sprinkled Management 3.0 with copious post-it notes and highlighted sections. I think I'll have to read the book at least 2 more times to fully digest the material. There are several main points I've taken away so far and I want to more fully explore and understand:

1. Management and leadership can be interesting. I thought the subject of project management was as dull as particle board until I read "Agile Estimating & Planning" by Mike Cohn. In agile, I  found planning and scheduling tools that were useful and practical to my daily life as a software developer. Management 3.0 seems to provide the same for leadership and management: how to empower teams, develop competence, facilitate communication, etc.
2. "Agile" is a memeplex. I'd heard about "memes" but hadn't heard the term "memeplex." Memeplexes are groups of memes. Memes grouped together in a memeplex because they are more successful when "teamed up." A lot of the elements of "agile" development and management aren't new or magical, but they reinforce each other when combined. I find "agile" and "lean" development subsume a large number of useful tools and ideas that work well together. For me, they have been more easy to understand, remember, and communicate when grouped together.
3. Leadership isn't just the domain of managers. Reading Management 3.0 has helped me untangle the big ball of elements subsumed by "leadership"and "management." I have a better understanding of the roles and responsibilities of managers and the difference between "governance" and "leadership." I haven't been a supervisor with direct reports for much of my career.  However, I have been a leader. I have acted as an adviser, architect, coach, mentor, and "competence leader" frequently over the years. I will be much more effective and confident as I gain a better understanding of management, leadership, and authority.
4. "Management 1.0" pervades my thinking. Somewhere my brain wiring has equated strong leadership with telling people what to do and placed faith in  "command-and-control" management (Management 1.0). Despite all I've learned through study and experience, those biases still linger. Those biases feel young and immature. Management 3.0 is helping clear up the muddle and gain a better understanding of the nature of complex systems. It's a much bigger deal than I imagined, and I understand why it's at the core of the book.
5. Practices not processes. I like studying, thinking about, and designing processes. However, I've never liked the idea of being the "process guy" whose job it is to impose rigid processes (thinking in these terms relates to #4 above). I was delighted to learn about this article, Enough of Processes: Let's Do Practices. I've found the best way to implement Agile processes is to do it our own way at the studios I've worked at. I've also noticed that places that supposedly do agile "by the book," make (what are to me) obvious mistakes and run into problems.
6. Manage the system, Not the people. As a person who loves to think about and manage systems, my favorite sentence in Management 3.0 so far is, "Manage the System, Not the People." My (not fully formed) understanding is that the core of the book is to treat teams as self-organizing systems and the job of management is to develop, protect, and direct the system. Before I read this, I told a person that I have experience as a development director and project manager, "managing projects and not people." I don't think I'll say it that way again, and I have yet to finishing putting together my pitch. Whatever the job titles are called, my interest is definitely in managing systems (it was also my interest when I was a software engineer).

Performance Metrics at Work

I'm in the middle of reading Management 3.0, a book about Agile leadership and management. The book has been thought provoking, and I would like to think and write about dozens of different topics. The subject that I've been thinking about today is "Performance Metrics," measuring individual or group performance at work.

In my experience, Agile usually just focuses on team performance, e.g., the Balanced Scorecard method described in the book Succeeding with Agile. The author in Management 3.0 argues for measuring metrics at multiple levels of an organization including individuals, teams, and higher levels.

I've worked in the software industry for over 20 years, and I've only seen the use of reviews for individuals with annual corporate "performance reviews." It's an ritual I always despise, both as a manager having to do reviews and as a person being reviewed.  I despise the multiple choice "satisfactory / unsatisfactory" questions. Right now I'll get angry even trying to remember them.  I liked having of list annual objectives in theory, but they never worked in practice: 1) a year is a long time, and there was usually no review or follow-up during the year; 2) what I'd written at the beginning of the year was often irrelevant because the direction of the company had changed so radically in the intervening time. I would have liked to see reviews or metrics done at higher levels of the organization. The top management usually rolled out nonsense goals every year like my favorite from Spectrum Holobyte, "Ship hits on time."

It makes me wonder what a good individual performance review process would look like. I've heard of "360" reviews, which are mentioned in , Management 3.0 and that sounds like a good idea particularly if done in a group meeting. Among Management 3.0's 8 tips for measuring performance, I was most taken aback by

• "Never create ratings yourself: The value of your opinion as a manager about the performance of a person or a team is very, very, very small. ..."

Upon reflection, I find I agree with this. Direct interaction with my manager is often been a lot less significant and frequent than my other work relationships: customers of my code and tools, departmental directors I'm supporting, etc.

Individual evaluation criteria and performance metrics I've seen have almost always been qualitative. I'm curious what useful quantitative ratings for individual software developers could look like, e.g., for programmers, producers, artists, designers. I've never worked in sales so "dollar sales" has never been relevant. I've been a fan of various agile team measurements: velocity, burn-down and burn-up charts, etc. Without measurement, I find both self-discipline and continuous improvement to be more challenging.