Pawel Brodzinski on Software Project Management

Google Wave: What You Should Avoid When Releasing Your App

2009-11-19T18:24:00.004+01:00

You can approach this post in at least four different ways. Your attention can be drawn by Google Wave part, namely my rant on the subject, or by a list of thing which you should avoid while shipping your application, which is a kind of lesson learned from the part one. You may also come here for both or neither of them. In the latter case I guess that’s quite a success I kept you here up to this point.

Anyway the whole thing starts with the story about Google Wave. Feel free to skip to the second part if you don’t feel like reading yet another rant about yet another Google application.

Google Wave

Lech invited me to try out Google Wave the other day. There was pretty much buzz on Wave recently so it’s a chance to set my own opinion.

I took my tiny netbook and logged in to Google Wave. The first thing is, what a surprise, an introductory video. A cool one. I could see top left corner of it. Oh I soon noticed “full screen” button on the frame so I could see whole video, which at the same time became completely irrelevant since the guy was showing other frames which I could no longer see since I full-screened frame with the video. Well, you don’t have another chance to make first impression they say.

Hey Google, have you ever heard about this little thingies called netbooks which are so damn popular these times? Yes, the ones with 1024x600 or similar screens. I must tell you Google Wave sucks when you use one of these.

I tried to play with Wave for a while trying to find the way of use just for myself. Nah, too slow, too feature-poor and too buggy. I thought it might be a replacement for good old Google Notebook but I couldn’t even paste a picture there, easy way.

But that’s all fine since they told us it’s the collaboration tool, didn’t they? And as far as remember there isn’t much collaboration happening between me and... um... me.

An occasion to test collaboration features of Wave appeared soon after. Along with Lech, Peter, Martin and a couple of others we shared two waves trying to run a discussion and collaborate online.

What can I say? First thing Google Wave is buggy. We found long list of issues which annoys us, huge lag on slower machines being probably the worst one. If the application you use cannot display characters as you write them something is fucked up big time. Hey Google, have you heard that these neat netbooks everyone uses aren’t very fast machines? Well, I tell you, not even close these fancy powerful machines you develop your code on.

Let aside quality. “Ship early” they said. What about functionality? A tough question. I thought about the most obvious scenarios like editing a document by a couple of people at the same time or a discussion on some subject or a hard-copy for intensive brainstorming... Actually none of these.

Co-editing a document is a flawed concept as a whole. If you try to write something and your cursor is jumping all over the screen because someone else tries to write his part just above you’re all “WTF?? What the hell is happening with this darn application?” I don’t know how the problem will be dealt with but definitely some other way than broadcasting each keystroke among all collaborators.

Over to discussion part. I must say threaded conversation in Google Wave looks neat. Nothing like phpbb forum. It’s really nice. You even get use to vague way of editing the conversation pretty fast. The problem is it becomes cluttered virtually in minutes. If you’ve seen some multi-threaded flame wars on popular portals you get what I’m talking about. It takes just a dozen of posts and you start losing your focus. After few dozen you no longer know which subject was discussed in which part of the thread, multiple sub-thread are forked by people utterly disagreeing with one little sentence thrown between the lines as a joke and people start wandering in different directions which happens during every uncontrolled discussion. If you happen to be offline for a couple of days finding any reasonable order in the thread becomes a great story for the next Mission Impossible movie.

Maybe brainstorming then? Maybe, if you try hard enough. This scenario is basically the mix of two above and you feel exactly the same pains. The main product of brainstorming ends up somewhere in the middle of conversation between “be right back” and “this feature sucks” messages. And no, co-editing the post doesn’t become easier just because it’s record of brainstorming.

And one more thing – every of these things you could do with other tools, namely Google Docs, any IM chat (Skype is fine) and shared mindmap (MindMeister anyone?).

This brings me to sad conclusion: Google Wave is released too early (e.g. is too buggy) and solves no real problem. What can we learn from this example?

What You Should Avoid When Releasing Your App

• Don’t release too early
If your software wouldn’t pass 15-minute acceptance tests of a person who just skim through the app it isn’t ready yet. Release early doesn’t mean you can release complete shit as long as it’s early. If the app is too crappy people won’t come back to check the second beta.

• Don’t release meaningless software
Solve at least one users’ problem. Choosing problems which are real helps much. You can generate a lot of buzz with being just cool, but folks won’t stick with the app. I keep coming back to Google Docs and Spreadsheets despite their (still) poor functionality because they solve a problem of as-easy-as-possible documents sharing. I keep coming back to discontinued Google Notebook because it’s the easiest way to group a bunch of hard copies of website pieces. Solve one yet unsolved problem and I’ll keep coming back to you because I’m too lazy to look for another, possibly better, solution.

• Don’t ignore people with worse hardware than yours
Think how a web application would look on low-resolution screens such as netbooks or mobile phones. I wrote about importance of optimizing your website for mobile phones a couple of years ago and guess what: people didn’t stop using their mobiles to browse the web. They’re browsing the web with their phones like crazy. And in the meantime the whole new market of computers with screens worse than good old 1024x768 emerged.

• Don’t overlook boring features just because they’re boring
If the most basic functionality is screwed nothing is going to rescue you. If your application sucks as displaying characters users type on keyboard you shouldn’t really bother about introductory video or widgets your app can have.

• Don’t forget about branding
A big name helps. If your company happen to be named Google, Amazon, Microsoft or such people will use your shit no matter what. You won’t hurt of a bunch of rants on your new product since that’s pretty much expected. On the other hand if no one ever heard about your organization you don’t want people to learn about you from a rant which is on the top of search results. If that’s how you start with your branding it may be a bit harder to draw other users.

Yes, I’m aware I sound so old-school and so boring. Feel free to ignore me as I’m not a typical early adopter. But don’t cry when people stop coming back after a couple of visits. And yes, you have their emails in your database but the only business you can make on that is selling them to some spammer since people aren’t going to give you next chance.

The Kanban Story: Implementation of Kanban

2009-11-16T18:50:00.005+01:00

So you want a story about the most painless implementation of new software development/project management methodology in industry history? Here it goes.

There was nice afternoon, sun was shining and air-conditioning was silently humming. One of our engineers asked me what about this new methodology we were talking about a couple of weeks earlier. So I described them how it works in details telling basically nothing more than could be found in great Henrik Kniberg's article on Kanban I mentioned earlier. It took definitely less than a half of hour, including Q&A.

Then we drew our Kanban Board discussing which stages we wanted to have. More about creating our Kanban Board in the next post.

The very next problem we have to solve was what exactly we want to move through out Board. We couldn’t decide on a color of sticky notes. I thought classic yellow would emphasize our respect for established rules of software craftsmanship while there were opinions that green would be better since it corresponds with stability of our software and flawless builds we get on our build server... OK, just joking here.

Actually the problem was what granularity we’d use on sticky notes. MMF (Minimal Marketable Feature) is a nice concept but sometimes too vague. Generally we try to use MMF whenever it makes sense but sometimes we use non-marketable features as well. Example? When we had screwed something in database structure we got “fixing up a database” post-it. Unless you freaking darn good marketer this isn’t "marketable" at all, but pulling flawed database with the product all along the way would be kind of a pain in the ass. Fixing it later would cost far more than doing it fast. This substitutes being marketable if you ask me.

To simplify things a bit we dropped using user stories. We decided using inside-out approach which in Tyner Blain article on agile prioritization is described as wrong one. The reason was most of the time splitting tasks in a way which was convenient for our development team created results which were identical with these achievable with outside-in approach (splitting tasks in a most convenient way for a customer). In these rare moments when it did not I could live with that and for me it maked development cycle more reasonable. Yes, I sure am biased with my past experiences as a developer or trying to play as someone like that.

Anyway we ended up rather with old-school features describing (hopefully) fine-enough-grained functionalities rather than scenarios describing how user would interact with the application.

Having this done we filled the Kanban Board with sticky notes showing what we were doing at that moment, what were planning to do and then we set up limits for each column. Again, more on this in another article about Kanban Board.

Basic setup of tools was completed. The rest was to follow few simple rules, limiting WIP (work in progress) being the most important one.

Basically Kanban was implemented and it wasn’t even a time of sunset, which we wouldn’t saw from our window anyway. We turned off air-conditioning and went home.

I know things start to look interesting barely now but feel free to check out the first few parts of The Kanban Story.

How to Reduce Number of Meetings to One per Quarter

2009-11-12T21:44:00.004+01:00

Meetings are boring. Most meetings are irrelevant. There are too many meetings we have to attend.

A confession: during past half of year I organized exactly two meetings with engineers in my team. Both were mostly about organizational issues regarding whole company, not just my team.

How did I do that?

Let’s start with why meetings are organized. Most of the time meetings happen to enable communication between people. Why don’t people just go to meet each other at their desks? Well, because they sit in different places, have different things to do and, often, have little free slots in their calendars. Sometimes they need to prepare themselves to say something reasonable and invitation to the meeting gives them time for that.

Basically all these reasons become non-existent when whole team sits in one place.

You don’t have to busily gather people from different places because, surprise, surprise, everyone is there.

You don’t have to wander what people do at the moment since, well, you just see it in a glimpse. You can make your call whether it’s a good time to interrupt them at the moment or you should wait for a quarter.

You don’t feel urge to finish in planned time slot even when the discussion is great and you’re solving problems like crazy. Neither do you feel this funny feeling when everything was said but no one hurries back to work and you just spend your time on chit chat because a meeting room is reserved for another half an hour.

You can even allow starting talking with folks on subjects they aren’t prepared to. You can because whenever they need to prepare they’ll tell it and a discussion will be restarted later. This is like instantly starting a meeting instead of sending invitations. Odds are everyone is ready and you don’t waste time. If they are not it works similarly to invitation with agenda but better since you start meeting as soon as everyone’s ready.

You should still think how improve transparency and communication flow but, believe me, once you start talking about almost everything in front of your team, even though you’re talking with a person next desk, people will know way more than they would otherwise. It would work that way even if you reported all your workweek on 4-hour long weekly summary with your team, which would be a candidate for the top dumb management practice of a year by the way.

And the best thing. With this approach you magically clear everyone’s calendar. Finding slot when everyone is free becomes the easiest thing under the sun because everyone basically stopped attending meetings.

A cherry on the cake: finding free conference room doesn’t bother you anymore.

Downsides?

It won’t work for 50 people. As far as teams aren’t bigger than 10 people it should do well. Vast majority of teams fall in to this category. Sometimes you need to focus and you don’t care about architecture discussion happening over your desk. You can take a break or try to isolate yourself with headphones. Either way it is a cost, but on average it’s significantly lower than it would be if you switched for old-school meeting approach.

This applies only to team-related meetings. If your people have a lot of cross-team meetings and spend long hours on company-wide roundups filled with jabber this doesn’t have to be huge improvement. But then you’re doomed anyway. One of my engineers attended a few meetings on coding standards beyond these two I organized.

The approach works best for engineers. Project managers and business people will meet other people more often that once per quarter but it should be still an order of magnitude meetings less than it used to be.

I wouldn’t get this kind of crazy idea but it happened so my whole team is collocated and it’s the best organizational thing which could happen. If you think it’s drastic, you’re wrong. Meetingless environment comes naturally. Maybe it so because this way you possibly are all time at the meeting, but at the same time you “meet” people only when it’s really needed.

Try it. And tell me what happens.

The Kanban Story: A Discovery of Kanban

2009-11-10T19:05:00.002+01:00

In the last chapter: A small team was built and they tried to set up a methodology for building their projects. After establishing a set of techniques and trying them against first couple of projects they faced a list of issues. They realized they needed something more. How would they deal with the problem? What would be their choice?

When I read Henrik Kniberg’s article Kanban vs Scrum it was first time when I thought I get the whole idea. I even thought it might work for our team but if you know me a bit you know I’m very reluctant to drop anything we’re currently doing just to try out this new cool idea I’ve read about yesterday. This is by the way the most important reasons why a few engineers with great potential I know will never fulfill this potential. They just can’t hold their horses whenever they read about new jazzy technology. And it doesn’t really matter whether it does any sense to implement it.

Anyway I finally decided to give Kanban a try since I believed it would solve both of our main problems. First Kanban limits work in progress (WIP) by design. Second having open backlog where I could put any incoming idea should help me with dealing with all different threads happening around our group and at the same time I should be able keep modifying priorities pretty easily.

What more, Kanban shouldn’t put on us much of constraints which would be invited by most of other methodologies. As lightweight as possible, as little bureaucracy as possible. Kanban suited well.

I checked team’s opinion about starting something new which would help us. When I described Kanban and prompted for feedback I got green light although I can’t say they were enthusiastic whatsoever.

A decision was made.

Read the whole Kanban Story.

Co-location Rules!

2009-11-06T19:44:00.005+01:00

A lot of interesting discussions today. During one of them we went through co-location and its influence of team productivity.

I’m lucky enough to work with all my team in one room. I’m aware of all disadvantages of grouping people doing different things in one place but I’m still saying I’m lucky.

• I know development requires focus. I know that grouping a bunch of people in one place generates some chit-chat which distracts people trying to focus on their tasks. I know occasional phone calls do the same. I accept the fact. Hey, have I just said I accept lower productivity of our developers? Bad, bad manager.

• I know most people would consider a private office as a huge improvement from open-space. I wouldn’t offer that to my people even if I had a chance to make them this kind of offer. Ops, I’ve just admitted I wouldn’t make my people happier even if I could. How come?

It just about trade-offs. While putting people together invites costly context switching because of distractions it also brings huge values in terms of team work.

• Instant problem solving. It’s enough one person to ask another one about some issue to see insightful discussion emerging virtually instantly. You don’t need to think whether PM should join since he’s here and he joins as soon as subject appears interesting for him. Solving problems as you go is much more efficient.

• Communication improvement. Communication issues are probably number one issue when it comes to visiting dead-ends, doing the same job twice or banging the wall hard with your head. When I think how much effort is wasted just because a couple of people didn’t talk with each other I believe every method which improves communication is worth considering and most of them are worth implementing. Co-locating people is one the most efficient choices here.

• Reducing number of meetings. Many meetings aren’t even needed. However they’re scheduled because they’re considered as the easiest way of communication between more than two people from different rooms. Remove walls and you’ll automatically remove many meetings. People will have more time to do the real work.

• Atmosphere building. Try to cheer up person who sit next to you. Tell a joke or something. Succeeded? Great. Now do the same with the person sitting on other floor. It takes walking and other tiring physical activities. It’s harder. You won’t do it so often.

• Getting to know people. You’ll know better a person after sitting with her in one room for a month than after working in different locations for a year.

And yes, I believe these compensate reduced productivity and happiness. Actually not only compensate but add more too. Net value is positive. That’s why co-location rules.

The Kanban Story: First Issues

2009-11-03T18:50:00.001+01:00

So we were doing great, everyone was happy and we were delivering on time on budget and on scope. Except it wasn’t exactly how things really looked like.

First two projects were late. Not much but still. It was expected since these were our first estimates in the team and at that time we decided not to do anything about that yet. Slips were reasonably small, which was a good sign when we talk about our developers’ estimation skills. Nothing to be worried about.

Another issue however appeared to be a real pain in the ass. One of applications got stuck somewhere in the middle of first iteration of tests. It looked like there was always something more important to do. Everyone was doing high-priority things and the application wasn’t touched even with a stick. There was no mechanism which would add an incentive to finish things and not leave even less-important tasks for later.

We also had a problem with our Product Owner. The guy was trying to catch many parallel threads and organize team’s work but unfortunately he was pushing in a bit too many new things. At the same time he was losing some of nice ideas on the way. Before some of them could be implemented guy was coming back from another meeting with a client bringing new, better and higher-priority tasks and the old ones were fading into oblivion. For those of you who can’t wait to ask who this crappy Product Owner was the answer is: yes, it was me.

A general conclusion was we need some more organization not at project level but at team level. Something which would help us finishing things and limit chaos generated by rapidly changing business environment. Specific of our team was we were doing a number of very small projects simultaneously so coordinating these projects was crucial to avoid falling into chaos.

We were about to do first process improvements...

Read the whole story.

Social Project Management Bullshit

2009-10-30T20:06:00.003+01:00

Level of buzz on using social media in project management and/or software development keeps on high levels for some time already. Social media this and social media that.

Social Media

Don’t get me wrong I’m not trying to say that social media is bad in general. Since I’m a blogger I would be a hypocrite, wouldn’t I? I see a value of social media while I’m trying to build community around this blog, meet new people and get engaged in discussions. That’s why I have Twitter account even though I’m not a big fan of the tool. I don’t treat Facebook account as a place to connect with people I know from professional life – it’s rather LinkedIn which works this way for me. I’m regular reader of a series of blogs and I’m pretty active on a couple of mailing lists, which is a kind of pre-social media.

Now, I know all these tools can work. They can when it comes to promote a blog or a book or to meet new people or even to deal with virtual teams when you happen to work in one. Up to this point they are useful.

Social Media in Project Management

But it doesn’t have to do much with project management. Twitter? Come on. Have you seen the way most people use it? Sharing private stories, which are sure interesting as long as they are from your close friends. Dropping links people find interesting, which is fine unless you realize there’s basically unlimited stream of interesting stories on the Web. Discussions which are followed only by a couple of people engaged in the discussion and for the whole rest that’s just noise.

Blogging? It hasn’t really made me a better professional. It works the other way around. My everyday work has made me a better blogger since it brings me new stories every week and a lot of real-life arguments in different discussions happening around.

Cost of Social Media

All these tools take time to use them. Time taken from the real work you used to do. So yes, you can twit about your cat and weather and share all interesting links on your high school and yes, throw in news or two about the project you currently work on. This is basically a waste of time. You can read all these fascinating stuff which appears in the incoming stream, which also steals much of your time. You can update your status on every social media site you use and start your day with Facebook etc.

The question is: how can you find any time to produce some code or manage some projects? And another one: how exactly does it help you in your work? I mean how many issues you have solved through Twitter or Yammer or something you couldn’t solve faster without using them? You know using the pretty old tool called “conversation” or the no-so-more-modern one called “phone call” or with at least with this Google thing.

Reason (Not) to Use Social Media

I know social media tools you can run a remote presentation or share some information within distributed team but be honest – how often do you really need them?

How often they solve virtual problem which would be non-existent a few years ago when there was no social project management at all?

How often social media tools are used just because they’re cool and trendy and it’s such a fun to use them at work and tell all people around how cool they are and how they help us in our work?

Social Media Bullshit

This is just social media bullshit. It’s trendy so people jump on the bandwagon not thinking much whether it’s useful and productive or quite the opposite. The same happened with agile by the way. When you see agile-by-the-name-only which looks like crap and works like crap and brings handful of arguments for agile-haters it’s most likely implemented by people who thought it was so jazzy to be agile they just couldn’t stand and had to start it.

This is exactly the same pattern you see among a specific type of developers who will dive deep into every new technology they read about just to try it, no matter if it does make any sense or not. When you recall people who wanted to do virtually everything with Ruby on Rails a couple of years ago you get my point.

If you evangelize to use Yammer in your collocated team of 7 you just do basically the same. If the only reason for changing your toolbox is that you want to use trendy social media tools it is plain stupid.

Of course there are situations where you need focus more on improving communication, e.g. virtual or distributed teams, but you also need to measure general impact not only on the team but on whole surroundings. Does switching from MS Word to Google Docs hurts other people outside of the team who happen not to have Google account? How about sharing documents with your customers? And besides that what’s so social about Google Docs?

Future of Social Media in Project Management

Social media are fun. Social media can be useful. Social media can help tremendously in specific situations for any profession, project management and software development included. However they’re very often misused just because they’re fun in the first place.

John Moore does some experiments with social tools, namely Twitter. I do mine. I believe Twitter is way more like blogs than like email. People start using it and then most of them abandon Twitter soon. There are loads of enthusiasts but it’s nowhere close to treat it like email which is already just another basic service we need, like phone calls. After all, usefulness of email is here because everyone uses it. You can’t say the same thing about any of social media yet. And it’s not coming anytime soon.

This is the main reason why social media will be basically used for, well, social reasons. These are social media after all. While projects are about people it isn’t the only thing you should care while running a project. Old-school methods, verbal communication being the most important one, work still exceptionally well in vast majority of cases. Is it really worth to change it?

Now, since I hoped to cause some stir I hope to see your comments too.

Are Fixed-Price Projects Bad?

2009-10-28T20:22:00.003+01:00

I’ve read recently a discussion about agile approach versus fixed-price projects. Several comments from the discussion:

“Doing a project on fixed-price/fixed-time basis since it’s unfavorable for a client.”

“If client insisted on fixed-price I wouldn’t sign the contract.”

“As long as there are companies doing crappy [fixed-price] contracts clients will insist on fixed-everything.”

“We believe that fixed bids are a bad idea when it comes to software.”

Whew, that was fun to read. I mean I love these kinds of strong opinions which omit plethora of real-life situations their authors (fortunately) have never faced.

I wrote pretty long argument why these statements aren’t very wise (not to say some of them are plain stupid) but I deleted it. Basically I have only one conclusion: being orthodox is always a bad thing.

The Kanban Story: Initial Methodology

2009-10-26T18:48:00.005+01:00

You already know how our team looked like and what concerns I had with implementing plain old Scrum. You also know we chose “take this from here and take that from there” kind of approach to running our projects. Our base method was Scrum but we were far, far away from accepting it the orthodox way.

What we finally agreed on within the team can be described in several rules:

1. Planning
For each application at the beginning we were deciding what we want to see there in the next version. We were trying to limit a number of features but didn’t set any limits how long development should take. The longest cycle was something between three and four weeks.

2. Requirements
When we’d known what we wanted to do we were creating user stories and non-functional requirements. Each session took whole team, even when someone wasn’t going to develop that specific application. As it usually happens the scope was being changed as we discussed different aspects of planned work. We were adding (more often) or cutting off (less often) features. We were building a coarse-grained architecture as we discussed non-functional requirements. At the end of the day we had a whiteboard full of stories which were a starting point for development.

3. Tasks
Since user stories were rather big we were splitting them to smaller pieces – development tasks. This was changing view from feature-wise to code-wise. Development tasks were intended as small pieces of work (possibly not bigger than 16-hour long) which were a complete wholes from a developer’s point of view. Ideally a single user story should have several tasks connected to it and single development task should be connected with only one user story or non-functional requirement. It wasn’t a strict rule however and sometimes we had many-to-many relation since specific changes in architecture (single development task) were affecting many usage scenarios (many user stories). Development tasks should make as much sense as possible for developers so they were defined by developers themselves and by those who were going to do the job. Tasks were stored in a system which was used company-wide.

4. Estimation
At the very beginning we had no strict deadlines but we were estimating anyway. There were two goals: learn to estimate better when there aren’t huge consequences for being wrong and getting into a habit of estimating all of planned work. Our estimates were done against developer tasks, not user stories. The main reason why we went this way was that tasks were smaller so estimates naturally were better than they would be if we did them against user stories. A specific, pretty non-agile, thing we were doing with estimation was a rule of estimating each task by a developer who would be doing it. More on this in one of future posts.

5. Measuring progress and work done
Current progress could be verified by checking actual state of tasks connected with a specific app. Nothing fancy here. The thing which was important here was writing down how much time it took to complete the task. When completed each task had two values – estimated time needed to complete the task and time it really took to do it. At the end of the day we knew how much our estimates were flawed. The important thing here was official announcement that no one is going to be punished in any way for poor estimates.

That was pretty much all. No stand-ups since we were all sitting in one room and we discussed issues and work progress whenever someone felt like it. No Scrum Master since, well, we weren’t doing sprints and within specific project things were rather self-organized. A kind of Product Owner emerged, impersonated by me, as we needed a connector between constantly changing business environment and the team working on different projects. You could say we needed one to bring some chaos to our work which would be equally true.

We were going to build a few small projects that way. At the same time we were prepared to improve the way we create our software as soon as notice flaws and find a way to fix them.

Keep an eye on the whole Kanban Story.

Setting Milestones in Start-Up

2009-10-23T17:46:00.000+02:00

This is a guest post from Richard Revis who is one-man army standing behind The Plan Is.

Which milestones have to be on your start-up plan?

I'm a project manager, so when I decided to start a new company the first thing I did was to draw up a plan.

Not everyone agrees that this is a good idea. The arguments against planning are numerous, and the biggest one is that in a start up things change so fast that a plan will be out of date before you get to day 2.

My own experience over the last two months has been that change is rapid and continuous, however the time I spent planning was not wasted as I am still working from the original plan with some minor updates. The key was to pick good milestones to aim for.

There are two types of milestones essential to any plan:

- Input milestones; these are things you do that reflect effort on your part, tasks like getting a website up and running, writing articles and technical milestones such as feature availability.

- Result milestones; these are outcomes of your work such as website traffic and beta sign ups. These show you how well the work being done is turning into customers, sales and money.

Only result milestones matter in the long run, however if you don't hit any input milestones there won't be any results. This is why both have a place on the plan. Input milestones drive you to get stuff done and keep you working hard. If you aren't hitting them you have a performance problem that needs to be fixed.

In contrast result milestones are valuable because they tell you if your plan is a good one. If you are missing your result milestones then you need to know as that lets you change your input milestones to ones that will help you get the results you need to stay in business.

How do you pick good milestones?

The right milestones vary a lot by circumstance, however all your result milestones can be reverse engineered from one date - the day that you will run out of money. The most important thing on the plan is that by this 'out of money day' your income is larger than your expenses.

My own result milestones, such as customer numbers, sign ups, website hits, and anything else which I can't control, are a guess based on data about typical conversion rates. For example a 1% website visitor conversion rate is normal for my industry, so my milestone is based around 100 times break even sales. Where data is bad or missing I have taken a guess and will update it when I find out how things really work. The milestone won't go away, but some of the details might change.

Input milestones are even more variable and will depend on your project, however it helps if they are enablers for results. For example 'website up and running' is a good input milestone because it is required for you to be able to achieve your 'first website visitor' result milestone.

The input milestones for my company are very high level and look like most normal development road maps. For example you would see entries such as starting open beta and implementing one customer requested feature. These are spaced out about twice per month, so that I always have a goal in close proximity. Knowing I have to tell my advisers which milestones I have reached every month really pushes me to keep working consistently.

How detailed should my milestones be?

The goal is to have a plan to measure yourself against, not an itinerary of the next six to twelve months! By keeping it high level and more adding detail one month in advance you have the advantage of knowing where you are going without boxing yourself into a losing strategy or having to throw the plan away.

This will also help keep your plan more realistic, as you can tailor the exact nature of the milestone to the circumstances at the time. There's not much point in adding milestones to your plan that can't be met.

An example of the milestones I have been working to can be seen in the accompanying table. One is still ongoing but I'm pretty happy with how things are progressing so far.

The minor changes to my plan that I mentioned at the start of this article have all been caused by too much detail. The exact features delivered to beta customers were not important so changing one for another didn't matter, however the overall milestone was critical to the company.

Having a plan is about helping you and the people you work with know where you are and where you are going. Selecting good milestones can make the difference between the plan being useful and a waste of your time.

About the Author:

Richard Revis has run technology development projects involving everything from iPhones up to front line fighter jets. He is currently Project Director at The Plan Is where he is developing web applications that make it easier to plan fixed duration projects. He writes regularly on project management and start ups at http://theplanis.com/blog

The Kanban Story: The Beginning

2009-10-21T21:21:00.003+02:00

So I found myself in this small team, part of a bigger company but working pretty independent of the rest of people here. Kind of start-upish environment. I knew every single person I worked with. Well, actually I’d chosen most of them and hired them here. The team was great (if you guys are reading this: no, it is not a reason to come for a raise) and personally I didn’t feel an urge to strictly control everything. On the other hand some order is always a nice thing.

Initially I gave a lot of thought to project management practices and didn’t come with a solution I was happy with.

I rejected PMP-based heavy-weight process which works for many projects in the organization. We didn’t need all the hassle they bring. At least not at that stage. A natural idea was Scrum which I didn’t like either. Scrum is pretty formalized methodology too and I wanted to avoid formalisms as much as possible. Actually with a lot of R&D work, pretty much prototyping and priorities changing all the time I needed something more flexible.

I didn’t want to be time-boxed since we were planning to work simultaneously on a few independent small projects which would be hard to synchronize if we wanted to put them all in one team-wide sprint. Creating independent sprints for each of projects was a complete overkill since you don’t really need Scrum sprint for a one-and-a-half-person project.

Actually I’d say we were at the point where we were too flexible for agile methods. Now, go burn me in flames for being iconoclast.

After some discussions we collectively agreed we wouldn’t adopt Scrum as a whole but would use some of techniques used there and some other ideas we thought were good. In the next post in the series you’ll find more details how we initially organized our development.

Keep an eye on the whole story.

The Kanban Story

2009-10-20T21:12:00.008+02:00

My current team works with Kanban for some time already. For all of us this is a kind of experiment on live organism. Ongoing experiment. That’s what led me to an idea of The Kanban Story – a set of posts which are a logbook of our cruise with Kanban.

The story has its beginning and several chapters since some things already happened since we started our friendship with Kanban. There’s no end however. I don’t know what we’re going to end up with but I’m going to share with you all ups and downs which we encounter along the road.

Hopefully this will become a kind of manual which helps with other Kanban implementations and generally with your work on projects and teams.

Technically it would work as pretty much every series on this blog – I will publish new chapter of The Kanban Story every week or so and you’d be able to find links all of them which are already published below since this post will be updated every time new post in series appears on Software Project Management.

Technical Leadership versus People Management: My Choice

2009-10-14T21:44:00.003+02:00

After last article about choosing between technical and managerial paths I was asked a couple of times what was my choice.

One of my friends who used to be my manager for some time once told a joke about me as a manger: “Pawel was a mediocre developer so we made him a manager.”

Basically, he was right.

I can’t say I was a great engineer. I can’t even say I was a candidate for one. This made my choice way easier. It was even easier when I realized I really like managing people. It makes me genuinely happy to see happy people and work done at the same time.

And yes, I sacrificed any technical expertise I had since I wasn’t able to catch up. I chose to spend any free time I had at work to learn to be a better manager than to keep my average technical skills.

This is the way it works. You can’t do both.

I’m happy with my choice. People I worked with in the past are willing to join me in my new teams so I guess I do a decent job as a people manager. I can’t say for sure what kind of engineer I would be but I believe I made the right decision.

When you make your own it would better be good since after some there’s no way back. The gap becomes too wide and you can’t just jump back.

Technical Leadership and People Management

2009-10-13T23:33:00.003+02:00

The other day I had a discussion about leadership and management. When we came to an argument that there’s no chance to advance to a position where you can facilitate leadership and management skills in discussed organization several people (from present and from past) automatically came to my mind. They all have the same problem which they may overlook.

They all are (or were) great engineers. People you’d love to have on your team. But at some point of their careers they started to think about having their own teams, managing their own people. Hey, that’s natural career path for great engineers, isn’t it?

Well, actually it is not.

Do a simple exercise. Think who you consider as a great engineer, no matter if he’s a star book author or your colleague no one outside your company knows about. Now what do they do to pay the rent? I guess they are (surprise, surprise) engineers, tech leads, freelancers, independent consultants or entrepreneurs. I guess there are none who would be called a manager in the first place, even when they happen to do some managerial work from time to time.

Why? Because these two paths are mutually exclusive. You can’t keep your technical expertise on respected level in the meantime, between performance review of your team member and 3-hour status meeting with your manager. You either keep your hands busy with writing code or you get disconnected with other developers out there.

On the other hand what makes you a great engineer usually makes you a poor manager at the same time. If you spend all day long coding, you don’t have enough time for people in your team. And they do need your attention. They do much more often than you’d think. If you’re going to be a decent manager big part of your time will be reserved on managerial tasks. There won’t be enough time left to keep on technical track. Sorry.

That’s why all these people who I thought of have to (or had to) make a decision which way they are (were) going to choose. Technical leadership path means most of the time you won’t have people to manage but you may be respected as an architect, designer, senior engineer. If you’re lucky enough you can even get one of these fancy business cards with title of Chief Scientist or Chief Guru or maybe just a simple Co-Owner.

Managerial path on the other hand will make you feel lame during basically every technical discussion out there but yes, you will have people to manage. If you’re lucky, and I mean lucky, not competent, you’ll become VP or something.

You have to choose. Or you had to some time ago. What’s your choice? What do you regret about it?

Automatic Localization aka Fix It Again Tony

2009-10-08T18:08:00.000+02:00

Localization is a good thing. Giving people possibility to use an application in their own language is even better. I know it. My native language is Polish which is known by much less than 1% of people around the world so it’s never even a secondary language for application developed anywhere abroad. Fortunately I can live in this big scary IT world since I can deal with English if I try hard enough.

However there are a lot of people who can’t or they just prefer to use the application which talks with the same language they used to say “mama” for the first time in their life. That’s why this whole localization thing is considered as important from time to time.

And we come to the problem what to do once you have your localized GUI ready. Basically you don’t just want to have just another branch of resources to maintain, do you? You want to show your users a masterpiece you’ve created while working on localized version.

So you automatically turn on localized version for each IP you identify as the one incoming from the country using this specific language.

And this is plain stupid.

Remember the story of Blogger when I was trying to publish a blog post while being in Austria? They automatically switched the language which I definitely didn’t want them to do. Now I know Google Analytics has Polish GUI. How? They automatically switched it. Twice. Without even asking me whether I wanted it or not.

Actually I didn’t. Why? Well, if you ask me what the hell “wskaznik odrzucen” is I can’t say anything more than you even though I know Polish pretty well. I just prefer to stick with English terms I’ve already used to.

Once I saw localized labels (which I didn’t understand) I instantly found settings just to find out the language is already set to US English. What the hell? Finally I got my English version back. Unfortunately last time Analytics greeted me once more with my native language. Hey, does anybody messed with my Analytics settings? Nope, I’ve just checked – the language is still set to US English. So… what the hell?

This reminds me a story why there’s no Fiat, which is one of the biggest Europe car manufacturers, in the US. They started with poor quality cars so the company name quickly became an acronym for Fix It Again Tony and finally they abandoned US market deciding the bad opinions are unfixable. Most likely it won’t happen again with Google but sometimes they try so very hard to repeat Fiat way.

A much better choice is to display a message “Hey, now we have brand new English version of our app. If you want to use it click OK, otherwise click cancel.” I can even live with seeing the message a couple of times before finally it baggers off as far as no one is going to automatically change languages of my apps. This is by the way the option which was chosen by Facebook when they were inviting Polish version of their site. I stuck with English one but somehow staying with the old option didn’t forced me to write a rant about that, which is a good thing I guess.

Keyboard Shortcuts in Web Applications

2009-10-05T20:29:00.004+02:00

What are differences between modern web application and good old thick client we used back than before internet bubble came?

One is responsiveness. Web applications generally suck when it comes to rapid response to user’s actions. Just today my friend told me how fast a time tracking app has become when he installed recently released Google Chrome add-on for Internet Explorer. If it wasn’t a web app he wouldn’t touch the application with that level of responsiveness. Not even with a stick.

What else? My call is usability. Web is still mouse-focused while most of old school thick clients are, or at least should be, keyboard-focused. The early web was all about navigating with mouse but that’s the old truth: keyboard is faster. The web should just mimic keyboard-driven navigation from thick clients, shouldn’t it?

Well, no. Not so fast. The problem is every web page works within some thick client – a web browser. Now, you can’t just use all these Alt+something or Ctrl+something since you don’t know which version of which browser your user launched.

Yes, Ctrl+O opens a file and Ctrl+S saves a file pretty much everywhere. But you don’t really know what Alt+N does in my Firefox and in my Internet Explorer. And as far as shortcut isn’t intercepted by the browser it will be passed to a web application. Unfortunately you can’t know when it is and when it isn’t.

The answer? I wish I had one which works every time but that’s not true. One great approach is the one used by Google Reader. They use characters and Shift+characters as their shortcuts. This doesn’t interfere with Alt+something or Ctrl+something used by browsers. Unfortunately this doesn’t work whenever you have a lot of text to be filled by the user since then you use letters and big letters to fill the text.

Another option? Leave shortcuts alone but make standard tab-pedaling as intuitive as possible.

Any other ideas how to solve the problem?

On a side note: a little hiatus here was connected with deployment of my private project. In other words: finally we have moved. There are glitches all over the place but the first service pack (term copyrighted by Szymon) is scheduled for the next year.

Change and Consistency: A Balancing Act

2009-09-22T19:07:00.001+02:00

For quite a few years already I’m lucky enough to have significant impact on a company, or a part of it, I work for. Being involved in strategy creation and then being a part of execution of this strategy gives pretty nice perspective – you know why some decisions are made and then you see what works, what doesn’t and what you do about that.

It’s no different now and since we’re pretty close to start-up-like organization there are way less strings attached than usual. If I had to point strongest drivers for what we do here it would be change and consistency. These two are always somewhere in a back of my head. And no, they aren’t mutually exclusive.

The funny thing is I’ve already pointed both of them (see links above) as critical factors of success.

Change is brought by the market itself. What you start with is wrong. Plan for it. Plan for change. It isn’t any different here. When our initial ideas appear to be flawed we either adjust them or abandon them. We look for opportunities which sometimes completely change our playground.

Consistency, on the other hand, is needed if you want to achieve any measurable success. It’s fine to switch business ideas two times a day. It’s a deadly threat to allow this approach to rule the development. Your builders can’t switch focus 3 times a week in order to satisfy another great idea which will end up in trash in a week or so. Priorities can change but with no consistency along the way you’ll end up with everything started and nothing completed, which is such a nice description of failure.

The key thing is to balance these two. On one hand you shall not allow to miss opportunities because of some code you actually work on, on the other you can’t kill you production cycle just because there are so many great ideas out there.

I believe we deal with this balancing act pretty well.

We discuss new ideas very often but almost none of them get instantly into production.
You can say it’s a kind of context switching, but at least it’s limited to design or architectural discussions. This builds confidence while we talk with customers because we understand how we’re going to build what we’re talking about. At the same time, hopefully, this approach limits unnecessary job being done as things tend to change several times more before a target design is ready.

We finish what we started.
There’s no excuse for job being started and not being finished. Even when something becomes less important because of late change of business priorities we bring the code to “shippable” quality and then move on to the next most important thing on the list. This limits the worst kind of work-in-progress, one which would never be finished because it has so crappy that even when you needed this code once more you’d start writing it from a scratch.

We carefully set coarse-grained development plans.
We incorporate as much features as possible into existing product instead of building quick-shot applications which are thrown away two months after creation. Specific features which are to be added changes a lot and backlog is rather capacious but in terms of product management we have no revolution – it’s a constant process of evolving to cover actual needs.

And yes, sometimes when we come back from one or another business meeting there’s a very strong incentive to call “hey, stop doing what you do now, here’s this great new idea which we earn zillions dollars on” but I’m happy we organized things in a way which basically doesn’t allow to do that.

The Value of Lessons Learned: The Art of Good Project Closure

2009-09-21T19:04:00.004+02:00

This is another guest post from Peter Taylor - The Lazy Project Manager.

Either you have been missing something, or nothing has really been going on

‘As we know, there are known knowns; There are things we know we know. We also know there are known unknowns: That is to say we know there are some things we do not know. But there are also unknown unknowns: The ones we don't know we don't know’ Donald Rumsfeld (Department of Defence news briefing).

That is one crazy set of words but actually there is a lot of sense in the whole thing. Here you are at the end of the project. It has been a success or, at the very least, is has not been a complete failure, and you are about to head off to the next project. But wait, do you really honestly know everything? Do you know what you don’t know? Well of course you don’t, you can’t possibly. So don’t fool yourself that you do!

So what do you do about it? Well what you do about it is to do something about it – now is the time to conduct a retrospective of your project, a review, a considered and open activity that will allow you the opportunity to learn what it is you don’t yet know.

Just as at the start of the project, remember ‘a brand shiny new project… at a point in time that is full of peace and love and general wellbeing between all parties involved’, well the end of the project is a special time as well. It is a time when project team members are far more likely to talk to you openly, equally and honestly. Therefore it is a time you should really focus some effort on to learn how to be more effective (and even more ‘Productively Lazy’) next time around.

Applying the ‘Productive Lazy’ approach

Finish what you started

As the Mastermind question master says, ‘I’ve started and so I will finish’, and you should make sure that you do the same. Finish the project in a correct and complete manner. Avoid all of those normal pressures and temptations to head off on the next juicy project that is calling you to.

Make the very most of this second opportunity of peace, love and harmony (hopefully) and learn everything that you can learn. It will be worth it I guarantee.

Know what you know

Start first with yourself. What do you ‘know’ about the project? Well a whole bunch of stuff that’s for sure, but what focus less on what you already knew at the start of the project and think more about what you have learnt new during the project.

Much of what happened will have been processed, dealt with, handled through the reapplication of past experience or knowledge, but some will have not. You learn through each project, so consider what it is that you learnt this time.

Now you know what you know and probably also know what you don’t know, gaps in your experience on the project, questions you can ask your team.

Find out what you don’t know

Now focus on the unknown unknowns. The ideal way to do this is to conduct a full retrospective, if you can’t do this then at least gather input from key members of your project team. One the best reference books for this Project Retrospectives by Norman L. Kerth (see references). I love the prime directive that Kerth governs his retrospectives by; Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

There are treasures out there, not one person knows all there is to know about the project, and certainly not you the project manager (you don’t honestly think your team told you everything that went on do you?).

So go gold mining, there are nuggets of gold in ‘lessons learned’ or at least lessons to be learned if only we pay attention. At least one of your project team will tell you something that will aid you in the future, and let you be a little more productively lazy. And the best way to make this happen is to plan for it to happen, right back at the ‘thick’ front-end of the project, back at the very beginning.

Ask what you now need to know

As part of this retrospective process make sure that you also take the opportunity to ask questions that you want answering. Remember? The things that you know what you don’t know, the gaps in your experience on the project, the questions should ask your team.

Complete your knowledge by having an open and honest dialogue with the team. It may surprise them what you don’t know, and they will most doubt be pleased that they were able to help out during the project.

Learn the lessons to be learned

OK, now let’s sum all this up. Carefully and slowly.

• You know what you know.

• You also know what you don’t know – and received answers on the gaps in your knowledge hopefully.

• You now know what you didn’t know you knew, through feedback from the team, and other sources.

• And, through the retrospective you at least know a little more about what you didn’t know that you didn’t know – if the team have been very open with you.

Simple isn’t it?

Tell others what you now know

And finally, don’t just sit on that knowledge. Share it out amongst everyone that could benefit from it.

Lessons learned should be lessons shared, so don’t be mean, share it out!

All the above can be summarised in this diagram. To move from unconscious incompetence to conscious incompetence, not knowing what you don’t know and just not caring, you need awareness – the retrospective can aid this awareness.

To move from conscious incompetence to conscious competence, knowing what you don’t know but caring about that fact – again the retrospective can aid along with a learning plan based on the outputs.

And finally, to move from conscious competence to unconscious competence – well just requires a lot of practice, so get to it!

A project manager’s tale of escape without cause

A story, and yes, I am the project manager in question, much to my shame.

For the most part I have really enjoyed all of my projects. That is not to say that there haven’t been challenges over the years; high points and low points, moments when I felt that I had had enough but equally good moments that I wanted to never end.

This tale is of a project within a manufacturing company that had a lot more low points than high points.

The project was ‘challenging’ (and it seemed close to impossible at times), the steering committee were ‘difficult (to say the least), the project team were ‘mixed’ in their interest and capability (to put it mildly), and I was a long way from home. The entire experience really tested me as a project manager pretty much from day one, but I felt that I had acquitted myself in a good way. In a good way until the very end of the project that is.

So, to quickly move to the point of this story, the project reached a conclusion. The deliverables were delivered and the company reluctantly agreed to signing off the project. The job was done.

Except it wasn’t.

I had had quite a hellish experience over the months and just wanted it all to come to an end. And so, when that final steering committee meeting was done and the minutes signed off, I have to admit that I almost ran to my car, jumped in and tore out of the car park deliriously happy. The motorway home called to me and, with some rock music blaring out of the speakers, I decided to right this one off to history and to never return again.

I was one happy project manager.

Then I was asked to go back and to a post-project review!

My heart sank and I began to make up 101 reasons why I was too busy, too sick, too mentally incompetent, too ‘about to go on a spontaneous holiday’, and too ‘I just don’t want to go back’, in order to, well, avoid going back.

I didn’t go back. Someone else did.

And so that was that.

Except it wasn’t. My inquisitiveness eventually got the better of me and I sat down with the other project manager, sometime after the review, and I discovered many things that I had never known about my own project.

I discovered (obviously through this other project manager) that the company had had a very bad experience in a similar previous project and, as a result, they were nervous about this project, very nervous indeed.

I discovered that the project had been strongly championed by one of the steering members despite a lot of resistance from others in the business and a lot, their reputation and possibly career for example, depended upon a successful outcome.

I discovered that two people on the project team had, shall we say, personal ‘issues’ during the early part of the project and this led to some residual tension between them.

I discovered that there was felt to be a ‘black hole’ in one particular business area where the purpose and benefit, the justification, of the project was never explained.

I discovered that they thought that I was a very strong and competent project manager, but one that focused perhaps not enough on the human side of the project.

And I personally discovered, and I did not have to be told this by my project management colleague, that I had missed a great deal by leaving the project before its final conclusion.

I personally discovered that I should have stayed for the full and proper closure, I would have learnt so much.

A final comment

These days I always try to complete some form of project retrospective, however light, whatever is practical – the benefits are many (and they can be a great deal of fun as well).

'Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.' Robert Heinlein (1907 - 1988)

About the Author:

Despite his title of 'The Lazy Project Manager’, Peter Taylor is in fact a dynamic and commercially astute professional who has achieved notable success in project management, program management and the professional development of project managers: latterly as Head of Projects at a global supplier of performance system solutions, and currently as Director of a PMO at Siemens PLM Software, a global supplier of product lifecycle management solutions. He is an accomplished communicator and leader; always adopting a proactive and business-focused approach. He is also the author of ‘The Lazy Project Manager’ book (Infinite Ideas 2009) – for more information - www.thelazyprojectmanager.com - you can also subscribe to a series of free podcasts on iTunes (The Lazy Project Manager).

Random Thoughts on Estimation

2009-09-18T19:14:00.001+02:00

A lot of discussion on estimation recently. A lot of great arguments but a lot of good old mistakes we’ve already went through. This brought me to a few random thoughts on estimating techniques.

Estimation technique which involves discussion between different people is better than one which just simply uses their estimates as input.
Using factual recorded historical data is better than basing just on experience.
Smaller tasks can be estimated way better than big chunks of work.
Every estimate starts with some kind of guess at the very beginning.

I know these should be obvious yet I’m surprised how often people:
- forget about them
- deny these are true

Then they head towards wild guesses with some magic number applied, which may have some sense but not when used instead of real estimation.

Building a House Agile Way

2009-09-15T19:30:00.000+02:00

Some time ago I wrote a series of posts where I compared specifics of my private project of building a house with my professional experience in project management. It would be hard to say these situations look the same although usually the same mechanics applies.

Talking about that, one thought struck me some time ago. When you build a house for yourself it’s most likely a purely agile project. I haven’t yet heard about investor who hasn’t changed anything in their house during its construction. Of course we rarely change outside walls etc, but inside a house there are loads of changes.

That’s pretty much expected since at the beginning no one really thinks where they would place furniture and what kind of furniture would even be there. We don’t think where exactly lamps or power plugs should be. These are details which we leave for later. Hey, who cares where exactly would save button be placed on an edit form while we don’t even know what kind of data would be edited there?

So agile, isn’t it? At the beginning just architecture design and then, through each iteration, planning in details what’s going to be done in short term. Embracing change. Actually while not every company which were working on my house were excited as I (actually my wife most of the time) was changing conceptions, I can say virtually every single one embraced change.

And charged for that.

And I didn’t really object.

Actually somehow that’s natural in construction world. Guys get plans. They build according to plans. If you have better idea and they have to, well, ctrl+x and ctrl+v a wall or something you’ll know they did the job twice when it comes to pay.

I don’t complain. If I told them earlier they’ll put it in the right place at the beginning. Except until I saw the first version I couldn’t tell I wouldn’t like it. What a pity walls are so hard to refactor.

This brings me to a point. Being on a client side I treat the agile way of building a house as a mixed blessing. OK, I admit I can’t imagine building a house according to BDUF specification with no changes at all so agile is a natural choice here. On the other hand it doesn’t come for free. I pay for each change which generates additional work. In other words I can’t define how big my budget should be to achieve functionality I want since I can’t say how many changes my vendors would have to embrace and how many iterations it would take to satisfy my (beloved wife’s) expectations.

Unfortunately shit happens and I actually had a fixed budget for the project, which in my case means I’ll run out of money before everything is done. And this is the place where agile sucks. Ten months ago a construction company came and said they would adjust reinforcement for this amount of money and they would change bricks to better type for that amount of money. And I was all “yeah, we should do it since we’ll have more freedom in arranging inside walls and the house will be warmer.” With this huge stack of money we had it didn’t look like a big deal anyway.

And no, I couldn’t plan how much exactly I needed for the rest of the project. I didn’t have all the details to be able to do that. You know, other way it would be old-school up-front design project, not the agile one.

Having said that, while building a house agile approach is the best possible option. One just needs to understand advantages and disadvantages of choosing this path.

One more thought for the end: I wish IT business were as aware of costs connected with change as construction business is (even though it's far from perfect there too).

PS. If you happen to visit me and would be curious where the heck a balustrade is or is this some modern way of finishing off stairs the answers is: this is the price of agile.

MockupScreens Review

2009-09-09T17:43:00.000+02:00

What’s your favorite tool to create a GUI design? Mine is whiteboard and a marker. Unfortunately it has some disadvantages. While windows and controls can be created rapidly whiteboard leaves you with pretty rough design. You don’t really think about specific positioning of all buttons and lists. You don’t think whether labels are fine or are they too long. You don’t think how a window changes when you display new controls. It’s all done when first working prototype is ready.

If you try to create clean GUI design you usually need some kind of tool for that. Usually IDE allows you to create clean sketch of GUI. A problem is that a person who should do the job rarely uses, and basically never needs other function of, IDE. That’s where MockupScreens appears.

MockupScreens is pretty light-weight application which allows you to prepare GUI design. You can prepare multiple screens using all basic controls and you can add some flow between these screens mapping actions (screen changing) with specific controls.

Strengths

Easy to use

MockupScreens is very easy to use. You need no documentation whatsoever to prepare your first design. You don’t have fancy controls at hand – just basic shapes, but that’s exactly what you need. You don’t try to polish your app – you’re building first version of your GUI. You definitely don’t need bells and whistles now. What you get instead is simplicity.

Gets the job done

It’s hard for me to get excited about this application. Building GUI sketches isn’t dramatically creative kind of task, you know. Anyway the big strength of MockupScreens is that it gets the job done. Not much more but nothing less than you’d need. Actually I always rant about lack of some features and this time somehow I don’t feel this urge. Strange.

Clickable prototype

A nice feature, especially for presentations, is you can create a usage flow of application you design mapping buttons on one screen with another. This way creating a clickable GUI prototype is very easy. This can bring you some ideas how you can improve your GUI. You can act like you heave working application with no development work whatsoever. Don’t show MockupScreens to your sales people.

Black and white screen mode

This feature was definitely proposed by one of the engineers. You can switch a design between desktop app, web app and black and white mode. The last one doesn’t try to imitate standard controls look but presents very basic design. This way business people wouldn’t think you have your app ready as they could think looking at clickable GUI prototype.

Weaknesses

Rendering speed

As you fill control options with data (labels, list elements etc) they’re automatically presented at your design screen. Unfortunately it’s slow. Oh so slow. It’s a bit frustrating when you try to fix a typo but actually a cursor is two characters after you.

Main editing area

I know I’m sick to work on 10,6 inch screen but this makes main editing area in MockupScreens pathetically small. There’s no rescaling feature either. This enforces heavy usage of both vertical and horizontal scrolls which I’m not very happy with. I guess this must be some kind of punishment or something.

Controls transparency

Controls which are used in MockupScreens aren’t transparent where there should be. It leads you to situations when you put frame on your screen and it hides everything which was there before. You can deal with it using Visio-like “bring back” and “bring forward” options but hey frame should be, well, just a frame.

Summary

Actually the best summary of a review is already written in the first two strengths – MockupScreens is easy to use and gets the job done. It’s a nice alternative for IDE features for all folks who aren’t developers and don’t need (and don’t want) Eclipse or Visual Studio installed on their machines.

As a test I created very simple design of one of web application we were recently working on and I have to say it was easier to present what I wanted to achieve with MockupScreens than with a drawing on a whiteboard. Basically what MockupScreens did was forcing me to put some order in my ideas how to arrange all controls and made me rethinking a bit whole GUI.

Having said that a whiteboard is still my favorite tool for GUI design but I’d go for MockupScreens whenever I need something more detailed with rather precise controls positioning. Using the tool is also a good idea whenever you talk with business people or a customer – they don’t necessarily have to appreciate your drawing (lack of) talent.

Why I Hate Document Templates

2009-09-07T18:44:00.000+02:00

This is a rant. Sorry.

The other day I opened a document describing some technical details we were waiting for. Ten pages. Whew, should be pretty much of content. Well, not at all. The first line of actual content was on page number 9 (yes, nine). On pages 1 to 8 you could find a lot of unimportant and uninteresting stuff which no one really cared about: table of contents with every piece set at page 4, preface which had neither been filled nor deleted, empty changes summary on page 4, some disclaimers and a bonus empty page. At the end there were finally one and a half pages of real content. Actually printing anything except of pages 1, 9 and 10 of the document would be a crime against forests and should be cruelly punished.

This is just a basic example how standard document templates are done. If you need to write down a simple minutes of the meeting there’s of course a template which, while empty, is 6 pages long. What the hell? A short document with a few ideas thrown on brainstorming session? Well, can’t do without table of contents, review summary and preamble. What did you think? Less than 5 useless leading pages? No way!

I usually end up with my own standard simple template: just title page and standard company headers and footers. I use it 9 times out of every 10 I need a template to start with. The funny thing is most of the time no one thinks this kind of template is even needed. And all these 10-page long (or longer) monsters are ready as soon as first set of templates is published. Too crappy to use them, too crappy to read them – just standard document templates.

And yes, the screen like above can be found in official documents of well-known, huge, global companies. So professional.

What’s Wrong with Workflow Systems?

2009-09-04T19:48:00.002+02:00

I recently realized that every company I worked for, except of one but it was so long ago no one can remember it anyway, developed and was selling their own proprietary workflow system. You know a kind where you can drag-and-drop some nodes and arrows, add users, actions and voila – the most complex business process is mapped.

What’s so special about workflow systems that everyone develops their own? Well, it’s a kind of The Holy Grail of business applications. You now, you have this workflow thing and you don’t need any other tool. You can configure every process there. Oh, maybe except a couple of them if given workflow solution is rather a specialized tool than a general one.

The problem is this kind of high level, general solutions very rarely fulfill expectations. And it’s no surprise if you ask me. If it was so easy we wouldn’t need ERP solutions, CRM systems, project management software, banking applications, bug trackers, you-name-it. We’d have one huge workflow which would be so complex no one would be allowed to touch the configuration and punishment for breaking this rule would be a headshot.

Of course there’s number of scenarios which suit perfectly to general workflow application but the interesting thing is why it’s so rare when companies look for external solutions instead of writing their own software. We buy a lot of tools but this one we develop.

I guess one of main reasons (a pretty common one) is “no one did it right yet but we’ll do it” way of thinking. There’s also another flavor: “no one had this problem before us” approach. Both are screwed. Actually there are pretty limited amount of people out there who face problems everyone else is yet to discover or have revolutionary and good answers for old issues. Chances are good you aren’t one of them.

If someone came to me and said “let’s make our own workflow system” a series of red lights would flash. Exactly the same which would flash if he came and advised to write our own ORM tool since no one else got it right yet.

Somehow it’s pretty common this kind of ideas make their way to the development. Why is it so?

There Is No Single Flavor of Agile

2009-09-02T21:05:00.003+02:00

Agile is such a capacious term. Under the flag of agile we do different things. Scrum is agile. And XP is agile. Scrum-in-the-name-only is also agile. We go with no plan whatsoever and that’s so damn agile is agile too.

Yes, you say the first two are true agile and others are fakes just tainting The Holy Agile Name. That reminds me... wasn’t it exactly the same with waterfall and others bad, bad techniques? Wasn’t they tainted by poor implementations which got everything wrong so we had to come with new better methods? Well, just a food for thought.

Coming back to agile. With all these good and bad implementations I can safely say that there’s no single flavor of agile. There never was. I believe it was never intended to be the only one. I recently read notes on the writing of the agile manifesto by Alistair Cockburn and one thing stuck with me:

“I came in through the doorway marked “Efficiency” not the doorway marked “Change” – because my background was in fixed-price fixed-scope projects. (…) Other people came to agile through the doorway marked “Change”, and that’s fine for them.

So although agile gets billed most of time through Kent Beck’s “Embrace Change” moniker, I’m not happy encouraging people to just change stuff all the time – it’s more efficient to think for a while and try to make good decisions early – the world will supply enough change requests without us adding to the list by not thinking.”

Different experiences, different projects, different backgrounds. Different accents when talking about the Manifesto. I can’t say I haven’t expected that at all but still. There was never one universal interpretation of agile principles yet we see every now and then people selling the only right and proper method of being agile. How come?

On a side note: I wrote this piece a few days ago. In the meantime The Big Ugly Change came and kicked my ass big time. “The world will supply enough change requests.” Couldn’t agree more these days.

Agile: The Good, the Bad and the Ugly

2009-08-27T20:59:00.003+02:00

Several agile “photos” which comes to my mind:

A presentation of a guy who implemented Scrum in his team in highly formalized environment in Motorola.

A series of Scrum trainings in a company which wanted to be oh so agile which ended up in virtually no change toward agile.

A person I’ve met on some event who told how much their customer was engaged in development process and how happy they were with results.

Implementation of new better agile process which ended up as a playground for a couple of people and brought nothing valuable for the rest of the team.

An environment where agile methods would bring only additional effort with not much, if any, gain.

A team which basically adopted Kanban in few hours.

Which one is real? Which picture shows agile at its true nature? Well, all of them. There’s no such thing as the only proper agile way. This is a lock-pick-word. Under the banner of agile we do good things but we also do bad things and ugly ones too.

When I think about agile as a phenomenon I consider all above as a part of it. If you try to divide good and reasonable implementations of agile from those done wrong or without understanding why it emerged around you reject to accept reality. OK, the part of reality.

If heavy-weight project management methods were done right all the time there wouldn’t be such strong drivers to change something in the area of software development and project management. But heavy-weight processes are bad because people use them bad. So the tool is wrong because people misuse it. OK, fine for me.

How misusing agile is different?

Agile became a buzzword for all good and bad which comes in a package. It’s adopted more and more, which is generally good, but at the same time a part of it is totally counterproductive and done just for the sake of being trendy.

The former is agile and the latter is agile. Even when the latter is agile-in-the-name-only it is still done under banner of agile.