Sprinting Up A Waterfall

A sprint, in Agile software development, is a period of time in which the scrum team attempts to deliver end to end user stories. These user stories should be demonstrated at the end of the sprint, to whichever stake holders are interested, at the end of the sprint. Simple. In fact it's a very simple concept to understand.

What a sprint isn't is a period of time where you develop user stories in isolation, and not demonstrate them at the end of the sprint. It is not a period of time where you continue waterfall style development and upon completion say you haven't finished yet. If you are working this way then you are not working in an agile fashion. Simple.

When Do You Acknowledge A Project Is Poison And What Can You Do To Find An Antidote?

There are certain software projects, that if mismanaged spiral towards mediocrity very quickly. Why do they not spiral toward a certain death? This is because in the end, most software projects deliver something. They may not deliver the product vision, but through all of the pain the team end up delivering something.

Why do I think these projects are poisonous? It's simple. In almost all cases no-one likes using or engaging with a mediocre product. Customers love using, and love sharing, products that exceed their expectations. Mediocre software deliveries rarely exceed Customer expectation and consequently rarely get used by the end Customer they were intended for. Sure there is the odd occasion that a mediocre software delivery is loved by the intended Customer base. This is rare.

Also mediocre products are rarely loved by the people that create them. If this is the case then the software delivery team will rarely promote their own work. They will rarely be proud in their work and in most cases they won't have an interest in taking ownership of their work. A sense of ownership within a software delivery team results in actually allowing the team to engage and grow with the product they they can then strive to improve to exceed expectations.

So how do you determine if your project is poisonous, and how do you deal with it spiralling towards mediocrity? A really clear indication would be if several, or indeed many, of the delivery team leave during the project lifecycle. This really should set alarm bells ringing, and theoretically trigger a response. Clearly acknowledging there is a problem is the start to finding a solution to solve it.

A group of people leaving a project is the clearest indication of a poison project. A pretty simple way of finding a possible solution in this case is to ask the people leaving what they think would solve the problem. even ask them if there changes were instigated would they consider staying? Who know's it might be the kick start needed to lift the project above mediocrity.

As an example in a previous occasion when a number of people left a project that I knew about, they mentioned that communication with marketing and stake holders was a continual problem and that no matter how much they tried to solve the problem they met brick walls that they could not overcome without further support. A simple solution here might be to sit the delivery team e.g. marketing and technology together. If this is done communication is no longer a process but rather an instinct. It is almost impossible for a team that sits together to not communicate better! If communication is an issue, remove barriers that are making it an issue. In this case what would there be to lose? Things cannot get worse!

Another means to determine if a project is heading towards mediocrity is to simply ask the people who are working on it if they are happy. If there are then it's a pretty safe bet that the project is adding to their level of well being and this typically would indicate a measure of future success on the project. If the team on a whole is down, then rest assured something is wrong with either the product or the process that is being followed to deliver it.

What can be done to fix this? Well the answer is simple again. Let the team decide how to fix it. A delivery team, in most instances, doesn't need to be directed from on high. A delivery team, if correctly staffed with the right level of experience, knows what it has to do to get something out the door. This is where the beauty of the Agile software delivery process comes into play. Agile promotes self inspection by the team who own the product and delivery process that they are working on. If things are not working correctly, then the team, not an individual, decides on the best approach to improve.

Two Sides To Every Coin

There are always two sides to every coin. I guess that is unless you have a one sided coin ;-). Firstly though, what is odd about the above coin?

So this morning I was reading about the Valve Employee Handbook. There are a lot of common sense solutions to the way the promote how they work and seemingly a lot of trust given to employees of Valve! If you have been asked to work there, seems they believe in you, and let you get on with whatever you feel you have to do to best provide value for the company. 

On the other side of the coin though, there is the environment in which trust is not felt as a necessity to empower employees to deliver a result.

Reading both of these after each other provides stark contrast of two very different working environments. I would suspect that only a sadist would be truly interested in the description of the second working environment! The reaction of the blog-sphere and on twitter would lead the casual observer to believe that most people would prefer the Valve method of getting product out the door ;-)!

Interview Tips Part 1 - Find Out What The Company Values

OK forget the above picture! Although it did make me giggle!

Recently I have had the pleasure of going through a few interview processes in order to get my career back on track. Although the interview process can be unpleasant, essentially you are selling yourself and to some that can be uncomfortable, it is definitely a challenge. If you like a challenge, to break the norm once in a while, then going through a round of interviews should help you out!

One thing I would stress is to not take the interview process lightly. Research the company that you are going to interview with. A solution that really worked for me was to find what the company values, and then think about how you would fit in with those values. A classic example are the Amazon Values. This tells you exactly what the company is looking for in all candidates. Pretty much well every company, that has an on-line presence, will have a similar page to the one at Amazon.

If the company you are interviewing with is actually serious about these values, then most of the questions that they will ask you should be able to be mapped back to them. So print out the values. See if you agree with them. If you don't, then you have to ask yourself why are you going to go for an interview with the company. It's a pretty safe bet that you won't enjoy your time there, if you are offered a job, as you disagree with the values that the company aspires to!

If you do agree with the values, then write down how you have met them and more importantly how you have lived them in previous roles, or indeed in your day to day life. If in your past roles you have not had the chance to aspire to the values, then write down how you would! Then read what you have written a couple of times to see if you actually believe in what you have said. Again if you don't then you have to think to yourself, would you enjoy your time with the company you are interviewing with.

If the company is serious about the values, that it is openly promoting, then most of the interview questions that you are asked should be directly mappable back to the values that you have studied. As you have highlighted how you have managed to aspire to these you invariably have a coherent and simple answer to provide in an interview. By studying what values a company aspires to, and determining if you believe in them, you are essentially able to find out the types of questions you might have to answer and you are then able to find the best situation, you have previously been involved in, that demonstrates how you personally aspire to that value.

If in the interview you don't get questions that relate to the published company values, then in my opinion you have to ask yourself whether that company is actually serious about them. Are their published values simply lip service that attention is never paid to. If you feel this is the case, then you again have to ask yourself whether you would be comfortable working in an environment like that. 

OK just because in a single interview you are not asked about anything that maps to the company values doesn't mean that the entire company doesn't aspire to them. You are typically interviewed by members of the team that you are going to work with though, so it might be an indication that the particular team doesn't aspire to them. Remember an interview is not a one way process. Sure you are going there to sell yourself, however the company that you are interviewing with should also be selling itself to you as well. If you don't get a great feel through the interview process, again you need to ask yourself, would you feel comfortable working there. 

Interviewing is not necessarily an easy or comfortable process. If you are not a natural sales person, then going out and selling yourself is not a trivial thing. It can be a very hard slog! Knowing, and understanding, the values of the company that you are interviewing with will at least help you know if you would be comfortable working there. It should also give you an insight into the questions that should be asked in the interview process. If questions are not asked in the interview, that can be mapped to promoted company values, then this should provide an indication as to whether the published core values are simply lip service, or actually aspired to. All great personal indicators to highlight if you would feel comfortable working in a company.

Next up STAR answers to questions ..... but this is another blog coming soon!

When Process Is Valued Over Innovation You Are In Trouble

If you deliver products to Customers in a market that driven wildly by innovation, lets say for example Internet services, if your delivery mechanism is bound tightly by process you are in trouble. This is as innovation cannot be governed strictly by process. It is not possible to simply say "Do something innovative next week". Sure you can allow someone the time to try and be innovative but this doesn't mean they will be.

Innovation is not something that can easily be measured and it is a continual process. You don't be innovative for a week and then spend the next 6 months delivering the innovation. Innovation means being able to adapt to new ideas and concepts as they inexplicably fall in your lap from time to time. You have to be able to adjust. Of course, arguably, this is exactly what the Agile software development process allows you to do. Adapt and change the process that is used by a self organising team so they can best suit the manner that is required to deliver a product that will delight Customers.

Of course if you work in an environment where following a set process is valued more than innovation and change. Then if the market you deliver in is fuelled by change and innovation - you are in trouble. Innovation invariably results in change. change to your processes and change to your products. Innovation is all about being able to predict a Customers needs and delivering that need. Or alternatively spotting a customer trend and delivering that trend. Of course spotting trends gets you into the market at best second, but by allowing processes to change and adapt, and products to change and adapt, at least you can be in the market.

If however you are dictated to delivering your product, without room for thought and innovation, and rather by steps on a spreadsheet, then invariably by the time you deliver your product, the market you are delivering it to will have moved on and your Customers will not be interested. 

The Scrum Process Should Drive Out Fear

I was interviewing a candidate recently and the question was asked "When you don't have clear requirements from project stakeholders, what do you do?". The candidate provided an excellent example of a project he had worked on, whereby he had simply provided the stakeholders with the requirements that he was going to implement, based on the vagueness that they hold told him, and then asked for comment. He then went about working with his team, delivering and demonstrating the requirements as they were built. His reasoning was that stakeholders were not providing clear requirements because they feared making mistakes and feared that what they were attempting to do would result in failure. His process of defining and demonstrating requirements, as they were built, drove out the fear and provided a platform for the successful delivery of a product. A great response to a difficult situation and a great interview answer. One well worth remembering ;-)

This is exactly what the Scrum delivery process does. With the product owner sitting in the scrum delivery team they are able to see early in the product delivery process the difficulty, or not as it may be, to deliver certain use cases. If the scrum team, prioritised by the product owner, attempt to deliver, and demonstrate complex use cases first, then it is possible to determine if certain use cases are possible.

Alternatively it is possible to see if product complexity will be detriment to the product as a whole, i.e. by concentrating on complexity first to guarantee it is delivered might not leave enough time towards the end of a product release schedule to complete the product as a whole.

By demonstrating sprint deliveries every 2 or 4 weeks the scrum team, at the behest of the product owner can self correct and re-prioritise functionality to ensure successful delivery. This might entail demonstrating the complexity of a certain use case, resulting in the product owner rethinking and reworking a set of use cases with stakeholders. The critical thing is that fear is driven out of a project as early as possible:

• The 'northbound' stakeholders (management) get a clear indication of progress at regular intervals. they don't wait until the end of a 3-4 month software delivery cycle to get an outcome they don't want. They can see at regular time intervals progress and if issues arise, expectations can be reset. There should be less fear from management as they have a clearer indication of what can be achieved. They get this vision at a very early stage in the delivery cycle.
• The product owner can also see progress immediately as they are sitting with the delivery team, working on the hardest use cases first. This gives the ability for the product owner to assess the over all project commitment and assess at a very early stage the chance of delivery success. The product owner then has the data they need to set expectations.
• The Scrum team can drive out fear as working closely with the product owner they can assess what can be delivered at a very early stage in the software delivery cycle. This gives the power for the team to self correct and concentrate on delivering the core value of any given product in a specified time frame.

This is one of the key benefits of the Scrum process. As the team are empowered, or should be, to deliver a product that they have ownership of, they have the power to set what is achievable within a given time frame. This means, as long as 'northbound' stakeholder expectations can be managed, that the delivery team can drive out fear as they can commit to what is possible, as opposed to worrying about what is not possible.

It is worth the 'northbound' stakeholders while to work in this fashion as if they drive a team to deliver, what cannot be delivered there are two possible outcomes:

• The delivery team will simply burn out trying to achieve the impossible. On the odd occasion they may well actually deliver the impossible, but it's no way to maintain the long term health and prosperity of a team. Undoubtedly there will be a lot of recruitment after each project as teams break up with individuals moving on elsewhere.
• The delivery team will simply become demoralised. This is as they will feel that their concerns are simply being ignored. Again expect to have to manage a lot of recruitment during and after the project.

the difficulty on the product owners part is:

• knowing what is hard and
• knowing what is impossible. 

If the product owner knows this, then hopefully prioritising what is hard, at the beginning of the project can drive out the fear. If they prioritise the impossible, then a load of time is going to be wasted not delivering anything. More on this later! ;-)

Cheers

m    

I'm Finally Leaving My Current Job

I am leaving my current job at the end of April. The almost universal response when I tell people is "Well done! It's about time!". The sometimes harsher response - "Well it's about 4 years late!". I would like to think that these comments are wrong and a little misguided. Unfortunately, deep down .... in fact not even deep down, rather quite close to the surface ... I know they are reasonably correct.

Ho hum. Onwards and upwards I say! Looking forward to new opportunities elsewhere!

A Successful Product Manager Has To Know How Their Product Is Built

If a product manager doesn't know how the product they are managing is built there is simply no way for them to be successful as they should be. That is unless they are carried by their team. It is essential that to make coherent and intelligent decisions about a product, that the product manager understands the impact that these decisions might have. The only way to do this is to understand how the product is built.

This doesn't necessarily mean that in a software development project that the product manager has to be a software developer. What it does mean is that the product manager works with the team to understand the implications of decisions. This understanding is facilitated by the product team sitting together. In a scrum sense, this means that the product owner, scrum master and scrum team all sit together. This means when an issue arises everyone in the team knows about it simply through work based conversation. Status meetings become less of a priority when the team sits together as immediately the entire team knows of an issue and can define ways to solve it - together.

By sitting together, even if the product owner is not a software developer, the team as a whole learns the impact of how decisions affect the team and conversely the team gains a finer understanding of why some decisions are made.

If the Scrum team and product owner are not co-located:

• The scrum team has no vision of why decisions are made and what 'north bound' management issues are influencing decisions
• The product owner has less 'south bound' vision of how stake holder issues impact the scrum development process.

The answer to overcome these issues is simple. A product team should sit together. A team that sits together by default will communicate more often, more clearly, solve issues far more quickly and pass on knowledge to each other through osmosis. This means that knowledge is shared without team members even trying to share it. This in turn creates a motivated team that learns together, delivers together and more importantly has fun doing so.

Co-location of a team is a simple mechanism to improve. 

Cheers

Murray

Negative Thought Blocks Creativity

Negative thought blocks creativity. That's it. Sometimes though when you are in an environment where negative energy is allowed to build it becomes challenging to accept ideas that might not be fully thought through. All to often the reaction is "That's not thought through - that's rubbish!". Sometimes this is a challenge to overcome, especially if the environment is in a glut, and not seemingly able to change.

The challenge then is how to overcome this, and how to do something yourself to promote change such that negative energy is not allowed to fester and destroy the creative process. There are many ways to address this, however one simple way is to start with ones self and not simply disengage with someone else's idea as it wasn't your own. Sure some idea's may not be thought through to completion, however this is exactly what the creative, product generation, process is about - working through a series of ideas to come up with a coherent set of engaging product features that your Customers will love.

In an environment where self is valued over team, this can be a real challenge. Nothing can seriously be completed if a creative process involves 10 people in a meeting room shouting over the top of each other, and not actually listening to what each person is saying. An idea needs to be logically explored to it's completion. There are many ways to do this, including hopefully an analysis of data to support a product feature. I think this however is the subject of another story. For now though rest assured that not listening to an idea and not exploring it, is a sure fire way to kill creativity, kill morale, kill team productivity and even worse - kill joy.

So here's a really simple tip. When you are in a creative meeting with others, instead of talking, first listen. Listen to what other people are saying before running with your ideas. If someone then gets in ahead of you with an idea that you think is brilliant, and that you were going to suggest, simply support them with their idea and build consensus that way. If there is an idea that you think is daft, ask the person who suggested it to qualify the use case for the idea and see how it might actually work within a product. Let the person run with the idea and provide support, if needed, and let their creativity flow into consensus. Who knows, that daft person might be the one who is actually thinking outside the business realm that you find yourself stuck in, and might actually be opening an entirely new stream of revenue for you.

Listening, promoting others to run with their ideas, and encouraging them to think freely by offering support to work through a thought into a deliverable concept, is going to pay off quickly.  This will generate a self motivated team that enjoy working together. This is a team that will want to deliver yours and their ideas, and turn them into a reality. What's more as they are a motivated team it is most likely they will exceed the Customer expectations as they will always want to deliver more than is promised.

Alternatively, as you are always right you could simply dismiss all ideas that aren't your own. You could do this, but when your delivery vehicle, i.e. your team, get that idea and are allowed to run with it to release, that run will most likely turn into a slow walk.

Cheers

m

What Agile Isn't - A Cross Domain Team Existing Only Of Product Manager Folks

Agile Scrum teams should be made up of team members across business domains. The Product owner should represent the needs of stakeholders and the Scrum team should consist of whoever is needed to deliver the product. This should include product designers, software developers and testers. Ideally all team members can work across disciplines, however in the real world this is most often not the case.

A scrum team should not consist only of Product Managers. This cannot be a scrum team as it cannot deliver anything. Some, although very few, would argue that a team like this can deliver the concept or a 'vision'. Arguably if this was the case that 'vision' would be delivered to a Customer so a Customer can engage with it. However unfortunately a 'vision' is not a deliverable product. In my view a collection of thinkers does not deliver a product.

This is often emphasised when a 'vision' is delivered to a delivery team and it is not possible to implement. There may be many technical reasons why it is not possible to deliver something. Some are so obvious that if a technical representative, i.e. someone from another business domain, were present in the team of thinkers many hours of wasted effort could have been avoided. This is precisely why scrum delivery teams are cross domain. Everybody that is required to deliver a product is available in the decision making process (or at least should be!). When this is the case if there is an impediment to delivery it is seen immediately, by someone in the team with the core knowledge of the reasons why, and can be analysed immediately. Then alternatives that could be delivered can be proposed, agreed and delivered.

Cross domain teams identify potential risks to delivery as early as possible and provide solutions to avert these issues. It is precisely why, when the concept of a 'vision' is discussed, that a cross domain team should be involved. The same principle of early issue identification and risk mitigation applies. By involving a cross domain team when the 'vision' gets to the delivery stage, it will actually be possible to deliver it, as opposed to spending 6 months fighting as to why it cannot be delivered.

Its a very simple, and obvious, thing to do when coming up with an idea.

Cheers

m

ScrumMaster Ceritification

I used to dislike the Agile methodology and in particular Scrum. It is only recently that I found out the reason I disliked it was because we were practising it poorly. Scrum is not about keeping track of development teams, rather it is about empowering development teams to deliver quality and respond to change efficiently.

Scrum promotes the concept of releasing software to customers when functionality is ready, as opposed to delivering a big bang approach - I.e. launching all functionality to the end Customer at the same time. This concept is antiquated and simply doesn't work. Get your product in the hands of a Customer as soon as possible and learn from their usage of it. This allows you to tailor any product deficiencies, highlighted by users of the product, as opposed to product designers who don't use your product! After all it is the end user who makes or breaks your product. Not the product designer. Not the product owner. Not the software developer. Nor even someone in senior management.

Scrum allows you to highlight risks as soon as they arise, as opposed to the end of a 3 month waterfall development phase when the testers first get their hands on the product.

Having seen the light, if not perhaps started practising it perfectly, I attended a ScrumMaster Certification course which was endorsed by the Scrum Alliance. I really enjoyed the course and found some of the techniques described, and some of the concepts explained incredibly valuable.

As an example before going I was always told that the entire scrum team had to work together to deliver their committed user stories for the sprint. This often led to clashes with the Product Design team members who always felt as though they needed to be at least a sprint ahead in order to be able to deliver designs to developers at the beginning of sprints. This clash always led to resistance from the design team to adopt the scrum methodology. This is simply not the case though. A scrum team needs to be self organising, so if design team members need to work a sprint ahead with the product owner, this should be perfectly fine. A team needs to be able to adapt to the needs of the entire team, not just the needs of the software developers. Self organisation, and empowerment to be able to self organise, are the key. Scrum doesn't say that everyone in the team needs to be working on the same features at the same time. What is does say is self organise into the best working mechanism for your team to achieve value for the end Customer.

After the course the course attendee is sent an email to complete their ScrumMaster Certification. This is done at the Scrum Alliance website. You sit through 35 multiple choice questions and at the end you get your results. The questions are incredibly easy, and if you have read any reference on Scrum it's a breeze. Embarrassingly I did get 2 questions wrong though!

One thing though, if you sit the test and the site takes you to a popup containing the test don't do this test! I did and at the end of the test nothing happened. After logging into Scrum Alliance again it said I still needed to take the test! On starting again the test we presented in the Scrum alliance website, as opposed to a popup, and on completing, my Scrum Master Certification was recorded against my Scrum Alliance profile. Why on earth there are two versions of the test I have no idea? Perhaps there has been a scrum alliance website update recently and my browser cached the old site? No idea? So if you see a popup don't take the test! Instead logout, refresh your browser, login again and take the test on the Scrum Alliance website!

Another small gripe. The time it took answered questions to be displayed on the site took an age. Page loads times, when I took the test, were incredibly slow. On two occasions I took incredibly slow page load times as mistakenly thinking I had not answered questions. When I answered again, instead of showing me if I was correct or not, I got an error screen saying "Don't answer twice" - not helpful! In honesty I just need more patience ;-)

Still having taken the course, I found the course very worthwhile. The certification exam seems a little meaningless, but it's done all the same.

Cheers

m

Addition: I should add that the trainer that I had for my ScrumMaster Certification was Martine Devos. I really liked the training she gave and the honesty with which she gave it. She concentrated on providing concrete examples of how she had seen Scrum applied through her experience. One thing that interested me though, was that Scrum is all about time boxing tasks. I felt that on the first day Martine did not time box her discussions well and that we ran overtime on several points. This was mainly due to students in the course asking many irrelevant (I thought anyway ;-) ) questions! This aside I enjoyed the way Martine taught and took many good ideas away from the course that I hope to implement someday.