Making the switch to Mac
A completely unrelated post, but I’ve been doing a lot of thinking about this lately ….
I recently purchased a 15″ MacBook Pro. I am also the owner of a seven-year-old PC running XP and a one-year-old Lenovo T41 running Vista. I’ve been a PC/DOS/Windows user since I left my Apple 2+ about 25 years ago.
So, I made the switch.
I’ve never been a strong advocate of Windows technology. Mac always bugged me because I was used to doing things in Windows, and I didn’t see the point of paying a premium for hardware that wasn’t any better. In recent years, there’s nothing a Mac can do that a Windows PC can’t, including desktop design, video editing, et cetera. I was also strongly tied to Windows for the software I used: MS Office, MS Project, et cetera. Not that you can’t get this stuff on a Mac, but let’s just say … it was easier to get for Windows.
But over the past few months, I couldn’t help but think: while Windows appears to get worse (more frustrating, more buggy, more power-demanding, more controlling) with every release, Apple just releases better and better hardware and software. I’ve also stopped using most desktop software. I use Google Docs or otherwise OpenOffice. I no longer use MS Project if I can avoid it. Open source and online applications have negated the need for expensive or pirated desktop software. Then Apple released their new lines of MacBooks, with the amazing multi-touch trackpad, a glass LED screen, and a gorgeous aluminum case. I couldn’t resist.
I took delivery last Friday, so I’ve had a few days to play so far. The design is beautiful. Performance is miles ahead of my T41, which by most accounts is a first-class laptop. It turns on and off almost instantly, and does wake up instantly. Installing software is ridiculously easy and fast. The multi-touch track-pad is brilliant — there have got to be about a dozen things you can do with it depending on the number of fingers you use and the direction you swipe. The only thing I haven’t go my head around yet is it’s management of various open windows … I don’t quite get it yet, but I’m sure it will come with time.
Another bit of navel-gazing I’ve done is one my relationship with Windows. It may seem kind of strange to think about having a relationship with software (or a class of software), but given the role computers have played in my life, the operating system I work with is actually a fairly important thing, whether it should be or not. I’ve used just about every flavour of Windows that’s come out (and DOS before that): 3.1, 95, 98, NT, 2000, XP, Vista. I liked 2000. After the second or third service pack I even liked XP. But even though I consider myself the kind of person who embraces change, Microsoft can really piss me off betweeen major releases with some of their changes, most of which don’t appear to make sense. I *really* struggled with Windows 95. I spent the first few days with Vista making it act like XP. Mac OS 10.5 has many things that Vista has (actually the other way around), and where they frustrated me with Vista, I can accept them on the Mac. So, I think it was time for a change.
So, I’m sold, although I’m not a fanatic convert (I don’t care about computers enough to be). I’m even starting to think about replacing that seven-year-old desktop.
Improving Velocity, or Getting Things Done
I’ve been asked by my project sponsor to come up with plan to improve velocity. This is a tricky area, and one which I’m approaching with caution. I’ve gone thought a few iterations of a document and found my perspective changing constantly. I think I’ve finally settled on a safe approach. My conclusions …
Velocity can be a false indicator of progress
I attended some six sigma training a while back, and one thing that struck me (I think this is a fairly standard criticism) is that while it can improve productivity, it doesn’t really focus on doing the right thing. This same can be true when looking at velocity. As a start, I can improve velocity by capturing more of the work we do in a sprint (e.g. meetings). Other things, like spending a sprint researching and implementing a new technology, also contribute to velocity. This wouldn’t have contributed to velocity if we’d got training and implemented some new technology in a quarter of the time. How is this benefit captured? This reminds me somewhat of the ‘false’ economy of disasters, for example. Oil spills add to a country’s GDP, but that doesn’t mean they’re a good thing.
With this is mind, one must be careful in simply presenting a plan to improve velocity. What I have said is that training in agile principles, as well as the possible use of a consultant to coach the team, will help. I’m still having trouble quantifying it. I can’t say our velocity will increase X% for every $X spent on training or consulting. All I can say is things should improve.
Getting Things Done or Not Doing Things in the First Place …
The other piece of this is how we can avoid having to do certain things in the first place, or get things done more faster by cutting out steps. Training, conferences, and even consultants can accelerate our progress in the project without ever changing our velocity (although they could possibly reduce the scope as represented in story points). The key here is identifying some of the things we need to do (estimated or un-estimated) and then finding alternatives. My architect could spend three weeks figuring out our business rules engine, or he could spend two days on training and accomplish the same task with another three or four days of effort. Again the challenge here is quantifying it. I can’t guarantee what impact training or in-house consulting will have in a well-quantified manner.
In this case I’m using past experience to predict the future. We can look at other training sessions we’ve had, and make a guess at the impact, both in reduced effort, increased quality, and new ideas. The problem here is that it’s just an assumption on top of a guess.
Anyway it’s been an interesting exercise and one that will probably be a lot easier with more experience in this model.
Lean Development for Lean Times
Yesterday I went to Agile Vancouver’s Lean Development for Lean Times event. It was a series of three speakers talking about different aspects of using lean with agile methodologies.
Katherine Radeka talked about lean product development, although I’d say the session crossed over into some more generic lean concepts, as well as discussing the cross-over from lean manufacturing to lean software development. There were some interesting ideas, but nothing earth-shattering for me, anyway. The best thing I took away from this was the idea of waste versus necessary waste. It’s a good way to think about some of those things which your customers don’t value, but you really have to do anyway.
Eric Ries was by far the star of the day for me. He’s an engaging speaker and I enjoyed learning about how he runs development in his business (the topic was lean start-ups) — definitely very lean and very agile. He uses continuous deployment to promote changes to production within 20 minutes, and has an ‘immune’ system which monitors how those changes impact users’ behavior so that bad ideas can be rolled back quickly. Well beyond what I’d ever need at my company, but I got some good ideas for improving things, and got a glimpse of what’s possible.
Last up for the day was Corey Ladas, who talked about Scrum-ban, which is basically applying lean principles to Scrum. Again with this talk I got some excellent ideas for refining our Scrum process to eliminate waste and refine our processes. I do think, though, that many of the concepts he presented would only be appropriate for a high-performing Scrum team within an organization with a reasonable level of maturity around agile concepts. Good ideas, but if I were to roll some of them out here, I think alot of things would break.
Overall a great event from Agile Vancouver, especially for $25.
Is Scrum a Project Management Methodology? Part II
I had a couple of interesting comments on my last post where I used definitions from both the Scrum Alliance and PMI to compare Scrum project management, projects, and project managers. When looking at definitions I couldn’t help but come to the conclusion that Scrum is very much like a project management methodology. The people who commented disagreed with me, but then I didn’t expect any different. I almost disagreed with me … I just let the definitions lead me to a conclusion.
There is more to Scrum and to project management than definitions., though. While I do think that Scrum can be partially understood from a project management perspective, I don’t think that’s the end of the story. Maybe that’s the crux of it — it’s not necessarily that Scrum simply isn’t a project management methodology, but that it is much more than a project management methodology. Defining it as such may only constrain people’s perceptions of it.
Scrum provides a way to define the work that you want to get done (the product backlog), a way to track that work (the sprint backlog and velocity), and way to predict when it will be done (sprint capacity and release planning), and some roles for people who aid in the process. I still say this is how Scrum is like project management.
So how is it more?
Scrum is a process improvement methodology. This has nothing to do with project management. Scrum is about continuous improvement, continuously questioning and redefining goals, and continuously ensuring you’re only doing the most valuable work. It’s also about constantly examining and exposing dysfunction at the team and organizational level.
Scrum is a team organization philosophy – that philosophy is that teams should self-organize and self-manage. They also play a role in determine what work should get done, and they decide how it will get done. This goes way beyond anything traditional project management looks at.
Scrum gives IT a new way to interact with customers. While project management techniques define certain roles around the PM, sponsor, functional manager, et cetera, they don’t address how an IT group can effectively interact with customer or the business. Scrum provides some great ideas here around stand-ups, product owners, and story valuation and prioritization that have nothing to with with project management.
Scrum is … I’m sure I’ve missed a few, but I think I’m getting the point across.
So, is Scrum a project management methodology? For me the final answer is yes and no. There are parts that can be viewed that way, but it goes so far beyond that that it may be misleading to describe it as such.
Is Scrum a Project Management Methodology?
Tobias Mayer wrote a post recently that Scrum has nothing — or very little — to do with project management, and backs it up with the fact that Ken Schwaber has stated often that there is no Project Manager role in Scrum. This got me thinking, because my first reaction is that Scrum actually has quite a lot to do with project management.
I’d like to exam this a little closer. I’ll start with a few definitions.
A project, according to “A Guide to the Project Management Body of Knowledge — Fourth Edition” (PMBOK), is “a temporary endeavor or undertaking to create a unique product, service, or result.” (p. 5). According to the same publication, project management is “the application of knowledge, skills, and techniques to project activities to meet the project requirements.” (p. 6). That’s pretty broad stuff, but you should be able to get the idea from it.
The Scrum Alliance offers: “Scrum is an iterative, incremental process for developing any product or managing any work. “ The Scrum Alliance defines a product or more accurately a product backlog as “a list of requirements prioritized by business value.”
So let’s take a look at this — the PMBOK tell us that project management is a way to manage work which is encapsulated in a project and the end result of which is a product or some other result which meets the project requirements. Scrum is a process for developing a product (which is a list of requirements) or for managing work. Pretty damn close so far.
What about a project manager versus a ScrumMaster? Now, I know that a ScumMaster isn’t positioned as being a project manager, but there’s no denying that this role is at least more closely aligned to the concept of a project manager than anyone else on the Scrum team. Onwards … .
According to the PMBOK, the project manager “is the person assigned by the performing organization to achieve the project objectives (p. 13). PBMOK elaborates: they manage and control change, progressively elaborate information, manage the team to meet objectives, and monitor and control the work (p. 9).
The ScrumMaster, on the other hand, “is a facilitative team leader who ensures “the team is fully functional and productive … .” In addition, they remove barriers, shield the team from external influences, ensure the process is followed, tracks work, and resolved conflicts.
There are some differences in the description of these two roles. I think the ScrumMaster description provides a little more detail, and in some ways just defines what the PMBOK calls “manage the team”. I know the idea of ‘managing’, though, goes against a key concept of Scrum and agile — that of self-organization. But in the end I think it would be easy to interpret these two definitions as being fairly closely aligned.
Looking at the thing (projects/products), the process (Scrum/project management) and the people (ScrumMaster/project manager) it’s hard not to come to the conclusion that Scrum is very similar to a project management methodology.
There are some key differences. Scrum is intended to help deliver software development projects, not buildings or events or whatever. Project management is intended to be applied in any area it’s needed. The leads to another question, though — can Scrum be applied outside of software development? I think it can (if I think back to courses and workshops I’ve been on, I know that Scrum can at least be applied to created a game and making paper airplanes), although that isn’t as clear a path.
In the end, Scrum clears away a lot of what traditional project management brings to the table — no stringent change control, no big designs up front with scope statement set in stone, no central project manager balancing all the spinning plates. It definitely feels different, but I’m not sure it is.
Implementing UI Design in Scrum
I’ve been looking around trying to find some good advice on how to integrate user interface design into and agile/Scrum process, but I haven’t found a lot helpful, practical material.
From what I’ve seen, there are two primary options:
1. Design as-needed during a sprint. This is definitely the more ‘agile’ approach, but it can create issues. Either your going to have to come up with a way to do some very rapid design work (back-of-the-napkin / whiteboard kind of stuff) or you may find your developers waiting for a few days at the beginning of a sprint while your designer comes up with stuff. This puts the designer under unfair pressure, and may result in your developers twiddling their thumbs.
2. Design one sprint ahead. In this scenario, your designer will work on design concepts for the next sprint during the current sprint. This is less agile, but gives your designer some breathing room. This is helpful if you have designers who are uncomfortable with a very rapid design process.
My preference is option one, but we have found that that introduces too many constraints on the process. Given that our project priorities aren’t changing rapidly, we can manage this level of pre-sprint work. Our business analyst also spends some of his time working on the next sprint, so it already fits a pattern we have in place.
Designers fall into the same category as business and quality assurance analysts — no less important than the developers, but they do play a ‘supporting’ role, and these roles aren’t expressely prescibed by Scrum. In the end, we’ve chosen the path that works for this team for this project. I think on a more ‘agile’ or frequently-changing project, we’d have to find a way to incorporate design into the same sprint. That’s a challenge for another day.
Scrum Retrospectives: Inspect and Adapt
So far we’ve been religious in performing retrospectives (although we misplaced our notes from the first one … not good). In my perspective, retrospectives are one of the most critical and highest-value aspects of becoming agile. The frequent review of how the team is doing, along with the discipline to incorporate changes quickly into your processes, should almost guarantee continuous improvement (and if it doesn’t you’ll know quickly). Retrospectives have given me confidence when we’re been faced with challenges in the process, or when the success we were hoping for wasn’t there. I know that we’ll have the chance to take a step back, inspect and adapt in the very near future.
Task-Based
Out of my CSM course I got the idea of only capturing deltas or changes. This avoids getting into complaint mode. You can’t say “people didn’t test their code well enough”. Instead you have to come up with a specific action item like, “make sure your code passes all the tests before passing it on to QA.” Where we can, we capture these tasks in new stories or incorporate them into existing stories.
Sticky Notes
My team has become a big fan of sticky notes. We use software to manage our projects, but we put up with the double effort of also maintaining a task board — the team likes the large visual. We also use sticky notes for our retrospectives. Everyone takes a few minutes to write down things that when well. I then gather them, read them out loud, and classify them. I do them same with changes or lessons learned.
The key value I see in doing this is that is stops more vocal team members from dominating the conversation, or influencing what other people might say. It also allows you to weight issues — if everyone mentions changes they want to see around the sprint planning process, for example, you can get a good idea that that’s a bigger issue for the team than if only one person mentions it. By classifying both the plus and changes, it also allows you to identify trends.
Check on Past Retrospectives
We start each retrospective by reviewing the changes or decisions we captured as issues previous sessions. This allows the team to (hopefully) see progress as we close issues that were previously identified.
Time-Boxed … not quite
We don’t actually do this, although I’d like to. So far our retrospectives have all approached (or surpassed) two hours. My hope is that as we get better with things, that time will be cut down. I’m a big fan of strict time-boxing, but I can’t bring myself to do it in the case retrospectives.
Retrospecting the Retrospective
We’ve definitely made progress in our retrospectives. While we never had to actually capture the change “don’t lose your retrospective notes” we’ve progressed from there (it’s always nice to start the bar so low) and I expect we will continue to.
The Agile PMP
A question came up today concerning how the Project Management Institute’s PMBOK or a PMP certification is relevant to the agile world. This has been written about and talked about before, but often with the goal of contrasting the two, or demonstrating the value of agile techniques over the tools and techniques PMI provides us. I’d like to offer my perspective on how PMI — specifically the PMBOK and a PMP — can help:
A Standard Lexicon
One of the great values of the Project Management Body of Knowledge is that is provides a standard lexicon for people who work on projects. I know exactly what a charter is, or what the difference between a project schedule and a project plan is. I haven’t yet seen anything in the agile world which provides such a rich source of standardize terms which allow people to communicate with the same basic understanding of what those terms mean.
Many of these terms are perfectly applicable to the agile world: projects still need sponsors, charters, risk management, and so on.
A Bigger Tool Set
One of the advantages I found in completing my PMP is that it exposed me to some parts of project management in which I’d had very little previous access. For example, while I’d had plenty of experience creating schedules, I’d actually done very little risk management. While having a PMP doesn’t inherently make one a better project manager, I think I did become a better project manager by getting exposure to different tools and techniques that I may not have come across otherwise.
Another great example is the information the PMBOK provides around cost benefit analysis, team management, et cetera. These aren’t PMI-only ideas, but they are critical in project management, and they are topics of study on your route to getting your PMP.
A Demonstration of Experience
This is probably a more controversial perspective, so I’ll start by saying that having a PMP doesn’t make anyone a great, or even a competent, project manager. There are very few, if any, certifications, designations, et cetera, which guarantee competency (I can’t think of any — I’ve met plenty of ignorant Ph.D.s in my life, and a few really bad MDs). But there are qualifications in place, as well as a fairly difficult test, which at least provide an indication that a person has the experience and education to be a decent project manager.
A Path to Organizational Adoption of Project Management
One of the big weaknesses I see in agile methodologies (well, Scrum anyway) compared to the PMBOK is that it is very focused on software development. I think this is changing, but it isn’t anywhere close to where PMI is. The PMBOK provides a guideline for the roles executive, functional managers, project managers, and team members can play in a project. It provides a path to integrate project management within different organizational structures. And it speaks to us in business terms that we can understand.
If an organization is already quite mature in its PM methodologies, this may not be much of an advantage. But for more formal organizations where there has been little to no exposure, I think the PMBOK can help — even for a move to agile. Which brings me nicely to my last point … .
The PMBOK Doesn’t Preclude Agile
The PMBOK doesn’t tell you how to manage a project. It’s not a prescription. It provides standard terminologies, it provides various processes, tools, and techniques, but it does not say ‘manage a project in this way’. A lot of what it provides makes a good deal of sense (start every project with a kick-off meeting, develop a project budget, et cetera). Much of what it offers does cater to more traditional waterfall methods, but not all of it … maybe even not most of it. There’s a good deal of information and many ideas that can easily be applied to agile methodologies.
I have both my CSM and my PMP. My CSM I got in a two day course with no test to make sure I paid attention (although a test is coming). My CSM, as well as a consderable amount of self-learning, has given me a new perspective on project management which I never would have got relying only on my PMP/PMI tools. But from a big picture, I still consider my PMP to be a greater asset. I’m fairly sure that’s not because of the dozens of hours I put into studying for that hellish three-hour test. I think.
The Trouble with Estimating
One of our biggest challenges so far is figuring out the best approach to estimating stories. From a project management perspective, I’d like to:
- Understand how much work we thought we’d get done in a sprint
- Understand how much work we did get done
- Understand how accurate our estimates were, at two levels: estimating the size of the story, and estimating the effort for tasks when the story is broken down
I’d like to understand these for two reasons:
- To help the team get better at estimating, and
- To help me get better at release and product planning
Our primary challenge so far is in finding a unit of measure which is applicable across all types of estimates. For example, the often cited proportional story estimate techniques (1, 2, 3, 5, 8 or XS, S, M, L, XL and so on) aren’t quantifiable. And in the end, the team is estimating tasks in hours (2, 4, 8, 16). Having a story that was originally ball-parked at a ’5′ or ‘M’ and eventually estimated in detail at 16 hours doesn’t do me much good, because it’s difficult to correlate the two.
On top of all this I wonder if I’m totally missing some critical piece of ‘agile’ thinking in trying to get this structure in place.
Right now, we’re estimating like this:
During a weekly story time, the team is estimating total effort for a story using 1, 2, 3, 5, 8, 13. Each number represents an ideal day of effort for the team. I can then translate that into hours, so a 3-point story works out to 24 hours. When we break the story down into tasks during our sprint planning, we can see what that really looks like — for example 30 hours. The one missing piece here is that in our original estimates we’re not taking into account how many team members will be working on a story — for example a 3-point story may or may not involve some heavy UI design, which would add to the total overall hours. I’m kind of hoping this will all come out in the wash. More likely I still have some thinking to do.
We just started doing this — I moved away from using the Fibonacci number as a relative estimation technique for now. I can see the value, bit it’s not working for us.
Besides figuring out if this will work and adjusting again, the next challenge is getting the team comfortable with this broad estimating technique.
