Marek Blotny's Blog

Developer’s point of view

If you ask developers how detailed the requirements should be, they will tell you that they want to know exactly what clients want to get. And this is good! Vague, high level, general requirements are not going to work for them. Everything has to be measurable so that developers and testers can easily, objectively, assess if a requirement has been fulfilled or not. To give you an example, if client wants to get a clickable button with an image and a label then, in ideal situation, developers would like to get acceptance criteria like:

• size of the image is 16×16 pixels, supported formats: JPG, GIF and PNG
• font size is 12 px and custom styling is not in scope
• label is mandatory and can have between 1 to 20 characters, only alphanumeric characters are allowed
• and so on …

To summarise it – expectation is to get technical details for each and every element.

Client’s point of view

Clients are usually much more high level, they operate on business level. It’s quite rare to hear from a client that they want a “clickable button with an image and a label”. They don’t operate on this level of details, not to mention the size of fonts or number of characters which can be entered as a label.

Much more frequently you will get strategic decisions like:

• IE6 is not a supported browser but still site in IE6 should be functional
• All component should be mobile ready – components should use all capabilities of mobile device and gracefully degrade from smart phones, touch phones to basic phones
• Site should be functional for people who have Java Script turned off
• and so on …

These are all sensible decisions but of course are too general to convert them into acceptance criteria just like that. The devil is in the details…

How to bring these two worlds together?

It’s obvious that there is a huge gap, details-wise, between decisions made by business and development team expectations. Primarily it’s a business analyst, project manager and technical lead job to minimize this gap and get both sides to understand each other. But is it only up to them to do the magic trick? I don’t think so …

To find the common ground, both sides have to step out of their comfort zone. Developers have to start thinking not only how to build a solution but also how to set constraints which will reduce complexity and effort to the minimum and in the same time maximize value for the business. It’s definitely not an easy thing to do. It requires good understanding of client’s needs, deep technical knowledge and experience to assess what solution will work and what will cause more trouble than benefit in future.

Business also have to be involved. Making a few general decisions is not enough for successful project delivery. Business have to collaborate with development team and help them transform requirements into solution.

It’s all about asking right questions

Development team which wants to get more detailed requirements can ask:

1. So you want this clickable button with an image … what formats should we support?
2. And how many characters you will need for a label?
3. How this button should be rendered, are 12 pixels for a label the right size?

Or situation can be like this:

Dear client, we have prepared an example of clickable button for you. We think that in this version everything looks good and all the functional requirements are fulfilled.

1. Do you think that image size is correct?
2. We think that supporting the most common formats like JPG, GIF and PNG is enough. Do you agree?
3. We have limited the length of the label to 20 characters to make sure that button will look good and consistent in all cases. What do you think about that? Is that a sensible limitation? If you want, we can extend this limitation but it will require additional 2 days of work because of something …  Do you think that 2 days are worth it?

I think you can see my point here. First set of question is easy but all the thinking is on client’s side. Second set of questions requires preparation and is much harder, especially in more complex cases.  I think second case is the way to show that we, as a development team, are adding some value. We are not just sitting and waiting for all the answers to magically appear, we are actively looking for those answers, we are providing technical expertise and this way we are helping our clients to make educated decisions.

What is the final goal?

Projects always have a limited budget (and requirements which are exceeding that budget). Final goal is to maximize return on investment for our clients. Not by working extra hours or running over budget but by

• figuring out which requirements have the most value and focusing on them
• helping to transform general decisions into a solution by providing recommendations and technical consultancy
• keeping things simple, low effort increases customer loyalty
• steering clients out of bells and whistles which are costly

PM can be a bridge between a client and development team but usually PM on his own don’t have enough technical experience to generate recommendations and provide technical consultancy. It’s an objective for entire team.

What are your thoughts on that?

In this post I would like to share with you quite cool logic puzzle. Real purpose of this puzzle is to reveal mental habit which is common for majority of people. I know, it’s very vague but that’s because I don’t want to spoil the fun

The puzzle

Preparation – You will need a pen and a piece of paper. Take the piece of paper and put on it nine dots in a way showed on the image below.

Rules – Your task is to draw four straight lines in way that all dots will be covered. To make it a bit more difficult, all lines have to be connected, end point of first line is a starting point for the second line and end point of second line is a starting point for third line…

Here is an example:

My lines are not exactly straight, but there are clearly four lines.

And that’s it really – now go and try to solve it on your own. There are not that many combinations to check so it should be doable within a few minutes.

Solution

Here you can download the correct way to cover all dots. I hope you have managed to figure it out on your own. If not then don’t worry – solution to this puzzle is far from obvious for majority of people. When I was trying to solve it, only one person of twenty five in a group has done it right. And that’s because that person had seen this puzzle before.

Key thing to notice here, to get it solved, is that you are not limited to area with dots. You can also use space around dots. People tend to make assumptions because “things usually work this way”. Usually in puzzles like that, there are lines representing boundaries, so it’s clear how big the game area is. In this case however boundaries are not defined. That’s something which completely doesn’t fit to scenarios familiar to our mind. And that’s exactly why we have made the assumption – there must be some boundaries, there always are! The easiest thing was to assume that outer dots are closing available space.

Of course that was just a game. Incorrect assumption was made and that’s all! No one got hurt, right? But imagine for a second, what are the consequences of incorrect assumptions made in the beginning of a project? Usually tremendous! Tell me from your own experience – are projects with incorrect assumptions made somewhere in early stages that uncommon?

I work with content management systems all the time. For me customization of CMS to client needs is a business as usual. I have done it many times. We, as a Cognifide, know how to do it and we are good at it. Risk here however is called - routine. With time people tend to stop thinking about basic things and take them for granted. We do make assumptions even without thinking about it. On the other side, our clients, in the same time also make some assumptions – about us, as a service providers, about a project or about a cost. They expect to get some things and this is not always communicated. Why? Maybe because we don’t like to waste time on talking about things which are obvious, right?

This puzzle showed to me that I’m not free from this mental habit; I do make lots of assumptions. It helped me to be much more aware of that. Also I’m aware that our clients are most likely doing exactly the same thing and it’s our job to surface those “obvious” assumptions. That is one of the reasons to keep asking “why?”.

My conclusions

1. Be aware that people simply make assumptions, sometimes even without thinking about it
2. Try to understand client’s intentions and goals to have better chances with discovering hidden assumptions
3. Be conscious and transparent with assumptions which you make. How? The simplest way is to write them down and make them available to everyone.
4. And finally – try to get distance from time to time and challenge your assumptions – try to verify correctness of them. Rule which was correct in past may not apply any more or may not apply to some specific project. It’s worth checking our habits from time to time and adapt if necessary. Seth Godin wrote once that decision before the decision is the box. Try to look on things from outside of the box – challenge your assumptions.

Final words … I’m sure that this game has some name; I have heard about it from a few different sources, it seems to be popular element of different trainings for marketers, sales people or managers. If anyone knows the official name – please leave a comment!
Moreover, if my post has inspired some thoughts in your head and you have enough time to share – please leave a comment!

In one of the previous post I was writing about estimates and commitments. I felt that this is an important topic because life shows that very often deadlines are beyond our control. I don’t know if it was only me, but I was living in a world where deadlines were always a matter of negotiations between a client and a supplier. Apparently this is not true for web development industry. This surprising (at least for me) truth was uncovered for me very recently when talking with the COO at Cognifide – Stuart Dean.

But if you think about it for a while, it actually makes sense. You have to realize that our clients are typically marketers. And for them, new website is most often only a part of a bigger venture. It can be a launch of a new product, new marketing campaign or some important for given industry conference. So from our client’s point of view all subprojects should end in more or less the same time. If one subproject has a delay then entire venture has a delay. In consequence new product or new campaign will be launched a few weeks later. And a few weeks delay can be converted into money not earned because of it.

Those are the market conditions we are living in. That’s why quite often we don’t have much room to negotiate deadlines. And that’s why the way to win and sign new contract is to come up with a realistic plan to meet those deadlines. Then simply we have to deliver them on time. I know – it’s easy to say, no so easy to do. But also that’s all what it takes to keep clients happy.

There are three simple ways to check if a team is really self-organizing:

1. There are always daily scrums, it doesn’t matter if scrummaster is present or on sick leave, self-organizing teams understand that daily scrums are for them, not for scrummaster
2. Team members voluntarily take tasks and work on them until they are finished. They don’t wait for scrummaster to come and assign something to them. Team knows what are the strong sides of all members, they know who should work on what to be efficient
3. Team members help each other to finish all stories. If each member is working on their own and don’t really care if others are blocked by something, this is not exactly the team work which self-organizing teams should have

Do you know any other quick tests showing if team is self-organizing or not?

If you are a member of development team, sooner or later someone will ask you to estimate something. It can be something small like a bug or task but it can be also something bigger like entire project. Regardless what that is, try to figure out what kind of answer you are expected to give. I don’t mean here that you should be trying to give the “right” estimate. I’m thinking about something different — usually there are two possible types of answers:

1. We need 12 to 18 weeks for this project.
2. We need 4 developers, 1 interface developer and 2 testers to have this project done before …. (some fixed date)

In the first case … you were really asked to give unbiased estimates, deadlines don’t exist for you. Project plan and deadlines will be planned based on estimates and negotiations with a client.

Second type is more interesting. It indicates that estimates are not the final objective, there is something more. Target (deadline) for this project is already set up front. So the real question here is “Can you come up with a plan to meet the deadline?” To answer it you need estimates, to provide a plan it’s good to know how big the project is. However keep in mind that it is only an intermediate step. It’s better to be very careful with this type of questions because even though you were asked for estimates, in fact it was a question about a commitment. By saying that you need given number of people to get something done, you are in fact giving your word that it can be done. If you don’t believe me then let me rephrase the second answer without changing the meaning into something like this “Sure, we can do it before … (some fixed date), we just need a team of 4 devs, 1 interface dev and 2 testers”

That’s why I think whenever someone asks you for estimates, it’s always good to check if the question is really about estimates or maybe it’s about a plan to meet the target.

What’s the relation between estimates and commitment?

Commitment is a promise to finish agreed functionality in given time. It doesn’t have to be the same as estimate. When you truly need to win a contract with a high-profile client then commitment can be more aggressive than estimates. You may assume that this contract will be a first step to a longer relationship and accept higher risk. On the other hand when you know about number of integration points and expect problems with them, you may want to go with more conservative commitment.

Generally speaking there are known problems and unknown problems. Some people say that unknown problems can be also divided into known-unknown problems (the one which we know that exist but we don’t know anything about them yet) and unknown-unknown problems (we don’t know anything about them and we don’t even expect that they exist)

Good thing about known problems is that you can solve them, workaround them or at least minimize impact which they have. In short – visible problem is a killable problem. Unknown problems on the other hand are hard to predict (especially unknown-unknown category is nasty) and you can be sure of one thing … Murphy’s law will work … they will show up and kick your ass in the worst possible moment.

So whatever you do, you want to expose as many problems as quickly as you can. Agile methodologies place emphasis on interactions and frequent communication with a client. Check how that can help you with uncovering problems …

1. Daily Scrums – prevent people from going dark. Everyday all team members are reporting what they are working on. It’s easily noticeable if someone has stuck with something. Daily scrums make hiding and struggling secretly with a problem very hard.
2. Short iterations and close cooperation with client – if for some reason you are building something different than client wants it’s better to know about it after a first few iterations than after entire development phase. At the beginning of a project you still have time to do something about it. But when you are after development phase, somewhere in the middle of UAT then your options are significantly limited.
3. Retrospective meetings – team is not as efficient as it can be? There are some bottlenecks? There are tools which are slowing team down? Or maybe you are experiencing communication problems? Retrospective meetings is a chance for entire team to meet and for half an hour stop thinking about deadlines, it’s time to focus on what went well and what went not so well and think what team members can do to make following iterations better.
4. Burndown chart and story board – visual representation of progress makes it easier to identify certain problems. For instance if you see that all of user stories are in ‘QA’ state (check attached picture) then you instantly known that something is wrong – there are not enough testers in the team. And finally burndowns … here you can see if your progress is good enough to meet the deadlines. From the very first iteration you can verify if your estimates where more or less correct. If not you still have a time to manage the situation.

I see daily stand-up meetings (“daily scrums”) as a one of the most beneficial practices in SCRUM’s repertory. Theory says that during the daily scrum each team member should answer three well-known questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

Daily scrum is a great example of small things which make great difference. Three simple answers from each team member ensure that entire team is on the same page. It’s clear who is working on what, what will be achieved by the end of day, what problems we have etc.

What I find strange is that theory doesn’t leave much room for any discussion during the daily scrums. Discussions should take place during the follow-up meetings, immediately after the daily scrum. In general I agree with this rule. Bigger issues which don’t require entire team can be talked through later.

But I think it’s much more beneficial for a team if all members are allowed to jump in anytime during the daily scrum to add anything they find helpful. I have seen many scenarios where such impulsive hints work very well. Although scrummaster has a tough task with keeping the discussion under control. On the other hand the worst thing which can happen is when team members are in ‘on hold’ state until it’s their time to speak. That kills spontaneous knowledge sharing and potentially turns daily scrum into a progress report with limited profit for a team.

It’s vital however to keep the meeting under 15 minutes and stay high level. There is not enough time for the team to go into each and every detail. That should happen during the follow-up meetings. Scrummaster responsibility is to ensure that discussions are on reasonable level.

So if you ask me if enforcing so rigid structure of daily scrum make sense. I will answer … definitely not! On one hand you have effective and useful daily scrums which encourage teamwork and on the other quite rigid structure and doing everything by the book. I’m far from saying that traditional approach doesn’t work, but it can be improved, so for me it’s a simple choice.

What’s your view on this? Do you think it makes more sense to follow traditional rigid structure of daily scrums?

Difference between running and managing a project is not negligible. You may think that this is just a wording issue and both alternatives mean roughly the same thing. But that is far from truth. Seth Godin is saying that running a project is “an active engagement, bending the status quo to your will, ensuring that you ship”. You are only managing a project if your concerns are limited to:

• Tracking progress
• Generating weekly reports for management
• Taking care for resourcing side of a project
• Resolving blockers for your team

I’m far from saying that the above objectives are useless or ease to achieve. However I see them as a starting point for any PM. If you are good at it, then great, but to become a really good manager and run projects you need to do a lot more:

• Keep an eye on project’s scope and make sure that it’s not mounting
• Look for bottlenecks in your team and eliminate them
• Make sure that there is a good communication between your team and a client
• Do whatever you can to verify frequently that your are building the right thing, that this is what your client needs
• Identify problems which may prevent your team for shipping and resolve them – “bend the status quo to your will”
• Make sure that your team knows exactly what is expected from them in all phases of a project

Seth wrote: “Running a project requires a level of commitment that’s absent from someone who is managing one” To run a project you can’t spend all day adjusting Gant charts in MS Project. You can’t sit all day in JIRA or Excel spreadsheet. You have to move your ass and talk with people, talk with clients, be active, be a leader. You have to leave safe waters and put yourself on risk.

What can you gain? Seth gives the best answer: “Who would you rather hire, a manager or a runner?”

I have been watching Cory Foy’s presentation yesterday. The presentation was about ‘Growing and Fostering Software Craftsmanship‘ but for me the most striking part was when Cory was talking about knowledge sharing and about Bus Number. Bus Number Wikipedia defines in a following way:

Bus Number is the number of developers on a project who could be removed before understanding of a particular part, or all of the codebase would suffer severely. The term refers to the fact that if these developers were unable to work on, or consult for, a project it would be difficult (or impossible) for new developers to pick up where they left off. In other words, if the developers were hit by the proverbial bus, the project would be in jeopardy.

So it’s pretty much clear that we want Bus Number to be as high as possible. We don’t want to see our projects to be so vulnerable. With low Bus Factor one unexpected event can lead to serious problems.

And here comes the most interesting part, Cory claims that in most organisations this factor equals exactly one! Think about it for a second … it means that entire project is in trouble with one person taking a new job, having a health problems or being hit by a bus. How bad is that?

Another point made by Cory – most organisations are not promoting knowledge sharing. Rewards and fame go to the people who know how to rescue projects, who are able to deal with complex projects, difficult clients. Knowledge sharing is not that high on the list, as a side-effect people don’t pay much attention to it.

I think usually people will agree that knowledge sharing is an important thing, but in the same time people tend to focus more on urgent things rather than important. As a consequence typical ways to share knowledge like code reviews, pair programming don’t happen very often.

What is the Bus Number in your organisation? How do you ensure knowledge sharing? Who should be the most interested in increasing Bus Number within a team? (PM? Tech Lead? or maybe someone else?)

Sooner or later developers have to start thinking about their career path. They are facing a question like ‘I have been programming for x year … now what?‘. As I see it there are three potential career paths for developers:

1. Well known path from development to project management
2. Purely technical path towards “senior developer” / “technical lead” / “software architect”
3. And finally third path towards technical consultancy

Quite often you can hear that developers are not good project managers. People say that mainly because being a good developer doesn’t make anyone a good leader or project manager. Programming and management require different set of skills.  Majority of developers got technical training and they lack soft skills which are essentials when it comes to managing people. However developers want to “progress” and in some companies this is the most natural way, the most obvious path. Transition to manager requires learning new competencies and changing “point of view” but for sure it’s possible.

Assuming that ex-developers feel good in the role of project manager  they have one big advantage over non-ex-developers PMs – they know what debugging is!

Every software developer knows how to debug code. When something goes wrong they can figure out what the problem is. Once the problem has been identified, they can figure out how to fix it. (In most cases.)

Ex-developers understand software creation process inside out. That puts them in much better position to investigate problems which may occur and solve underlaying issues. For them project is not only about tasks, estimates and tracking progress. They know what is really going on. PMs without technical background usually have following options when the project is in trouble:

• additional people to speed things up
• overtime hours
• functionality descope

Ex-developers are not limited to the above list, this is their strong side!