Risks, Assumptions, Issues and Dependencies (RAID)

This post is about a tool that is useful to have when doing Release Planning.

During Sprint or Release Planning it is useful to capture any Risks, Assumptions, Issues and Dependencies that we identify during the planning, that might impact the successful execution of the plan. A RAID diagram is useful for this.

Setup 4 flipcharts on the wall, where the team can capture Risks, Assumptions, Issues and Dependencies.

Risk

A risk is something that might happen. Should it happen it will have an adverse impact on the success of our project. Risks should be discussed openly by the team. We need to evaluate how likely they are to happen and what mitigation actions should we put in place to avoid or to counter them.

Here is some good advice for managing risk

Examples: There is a transport strike looming for the next number of weeks, so it will be difficult for people to get to the office. Peter is doing maintenance on an other high priority project; he might get pulled on a regular basis from this project if there are issues for the customer.

Assumption

An assumption is something that we think is true or likely to be true and we rely on it being true to successfully delivery our project. Assumptions should be tested as early as possible during the execution of the plan.

Examples: To cause least disruption, 21:30 is when we think we have least number of users on line so it's the best time to upgrade our system daily.

Issue

An issue is something that is causing us a significant problem today and prevents us from succeeding in our project. The main difference between Issues and Risks, is that Issues are a certainty today. Issues need to be dealt with all the time. It's important that an owner is identified and a strategy for dealing with the issue is agreed. Can we resolve the issue ourselves? Do we need outside help? Can we avoid the issue altogether?

Examples Issues: We have scalability problem after 10, 000 connections to the database. Mary, the principle tester, is going on 2 months extended leave for July and August.

Dependency

Something that must be delivered before we deliver our project. Dependencies must be managed and monitored. How are we going to make progress while we wait for this dependency? If dependencies run late, how will that effect our delivery? Can we minimise that impact?

For example: We are using a beta version of our platform for development, and it's due to be officially released 6 weeks before we go live.

Team Building Exercise: Tennis darts game

This game is a fun game to promote team communication. Good introduction to new team mates.

This is one of a series of simple and fun team games to help team forming.

Team:

4-8 people

Aim:

to score the hightest number of points by landing the bean bag inside the scoring zone.

Equipment:

1. Spray paint
2. Tennis racket
3. 6-8 mini Bean bags ( or a balls that won't bounce)

Course:

1. Draw out a large circular target on a large area. 4m-10m in diameter.
2. Draw some smaller circles inside the large one. At least 5.
3. Mark out a base approx 15m from the target zone.

Scoring:

1. Smallest circle in the middle gets 200 points
2. Next circle gets 15
3. Next circle gets 12
4. Next circle gets 9
5. next circle gets 5
6. Outside that the score is 0.

alternative scoring: Use hula hoops placed on the ground, further away hoops get more points

Instructions:

1. Allow one practice bat per team member.
2. Each person takes the racket with one bean bag.
3. They stand inside the base.
4. They launch the bean bag towards the target on the ground, using the tennis racket.
5. Repeat for the next 5 bean bags.
6. Add up the scores of where the 6 bean bags landed to give the team score.

Team Building Exercise: Risky Bowling

A great game for team building, it promotes communication around risk. Do team members keep it safe and score for every roll. Or do they go for broke and try and maximise their scores, at the risk of scoring nothing.

This is one of a series of simple and fun team games to help team forming.

Aim of game:

To score the highest points score by rolling a ball to a stop between the lines on a lane. The highest scoring zone is furthest away & the smallest zone. Be careful not to over judge the distance, as this score will be 0!

Team:

2-6

Equipment:

• Level flat surface
• Coloured tape
• 10m+ roll of carpet, 1m wide
• Bowling balls or large tennis balls
• Measuring tape

Course:

• Lay out the carpet.
• Mark off an area after 3m, 5m, 7.5m, 8.5m, 9.25m, 10m

Scoring:

1. 0-3m Zone 1 - 1 points
2. 3-5m Zone 2 - 3 points
3. 5-7.5m Zone 3 - 5 points
4. 8.5-9.25m Zone 4 - 8 points
5. 9.25 - 10m Zone 5 - 30 points
6. 10m+ Zone 6 - 0 points

Instructions:

1. Allow one or more practice rolls per team member.
2. From behind the start line, roll the ball along the carpet.
3. Where the ball rests is the individual score.
4. Repeat & add up all the scores for the team score.

Team Building Exercise: Gutter Ball Challenge

A great game for whole team interaction. Promotes teamwork, communication and lateral thinking to achieve the goal as fast as possible

This is one of a series of simple and fun team games to help team forming.

Aim: To transport as many balls from one bucket to another using gutters

Team: 4-6 people

Equipment:

1. 2 buckets
2. 5 x 1 - 1.5 meter lengths of PVC guttering. To make game harder, use down pipes
3. 100 tennis balls (bucket of tennis balls)
4. Stopwatch

Scoring:

• 3 minutes after the clock starts.
• 1 point per ball.
• 200 points if all 50 balls are transported successfully

Course:

Place the bucket of balls in a space.
Place the empty bucket approx 5-20m away. (Further away, game more difficult). (10M)

Instructions:

1. Allow one or more practice runs per team member.
2. Start the clock.
3. One person stands at the bucket of balls. They cannot leave the bucket and are the only one who can handle tennis balls.
4. The remaining players take a gutter each and line up between the two empty buckets. They should stand so that end of each gutter touches in a line.
5. Persons who hold a gutter can only move or walk when there is no ball(s) in their gutter.
6. Person at the bucket, places one ball on the first gutter.
7. The first person passes the ball, via tilting the gutter towards the next gutter.
8. Once the ball is passed the first gutter, the first person runs to the end of the line.
9. Once you reach the destination bucket, deposit the ball into the bucket using the gutter. All return to the start.
10. Continue until time is up or all balls are transferred.
11. Count the number of balls transferred.

Penalty

Should the person with a ball(s) in their gutter walk or run, the ball is deducted from the total.
If a ball falls, it is lost and cannot be picked up again.

Hint:

You can try to transfer more than one ball at a time. You may have more than one line at a time. However let the teams figure this out themselves.

---

Updated 13/12/2018; spelling mistakes corrected

I did pair programming with my colleague, do I need a peer code review?

In my opinion the short answer is: yes

Pair Programming is a tool to aid production of an artefact, be it code, a user document, an email, a presentation or some other artefact.

Peer Review is a quality assurance tool or checkpoint in our process. We are checking the output of the production process. Lack of knowledge of the production process is a benefit for Peer Review, however you must understand the problem being solved. It is a clean set of eyes over the problem and the proposed solution.

Pairing and peer review are therefore complimentary and neither one depends on doing the other. It’s a good idea to do both. We know that pairing during production produces less defects. We know that peer review helps catch defects before the customer gets the product.

What pairing means for peer reviews is that we should find less issues and for those issues we find, their solution should be less time consuming. There should be less "returning to the drawing board". But pairing doesn’t mean we should no longer do peer reviews. A good quality process demands a quality checkpoint.

Updated 15th August, 2016

Email communication

The single biggest problem in communication is the illusion that it has taken place. George Bernard Shaw

In this post, I propose that email amplifies the illusion of communication and it should be avoided on most occasions.

Reliable communication is one of the biggest challenges of the human race, not alone the software development workplace. Effective communication is as equally dependent on the receiver, as it is on the sender or initiator of the communication.

There are a significant proportion of our engineering fraternity who demand and insist we use email because it's become an integral tool in the office place in the last 25 years. However, contrary to popular opinion, I would like to propose that it has to be one of the worst communication mediums.

In agile we favour Individuals and Interactions over processes and tools, so at an academic level we agree that email is terrible (it's a tool!), but practically day to day, we don't live it.

I see at least the following short comings of email as a medium for communication.

Problems

Feedback: The first problem with email communication is the lack of feedback on the message we deliver. Unless a receiver actually replies, we can only assume they read the message and that they understood it. Generally you only get a swift response to an email when you made an obvious mistake or the receiver strongly disagrees with you!

No tone: Communication is not just what you say, it's also how you say it. The same words said in a certain tone, have completely the opposite meaning (sarcasm). It's very difficult for the reader to detect the tone in an email. All we have is the literal words. However, often the email sender will compose the message as if they are saying it to the receiver, in their head - tone and all.

Mistakes: We easily make mistakes in what we write or type and it's nearly impossible for us to spot our own mistakes.

• Grammer matters, for intent. A comma missing or inserted incorrectly changes the meaning of a sentence.
• We can easily leave out a word - this can invert the meaning
• Fundamentally many of us can't proofread our own mails (Pair email writing?)

Temporal aspect: We can't control when the reader reads the information. With the spoken word we have instant receipt - we can watch the facial reactions of the receiver. With email we assume the reader reads our mail pretty soon after we sent it.

Speed reading: We don't read every word because we quickly read email and loose out on critical detail. Or worse we click on the mail in their mail tool and think they have already read it, but didn't at all.

Volume = Noise: In my experience, the sheer volume of email I receive daily, makes it easy for me to miss important events and information. Some tools help by filtering mails - so you need to know who's "more equal than others" and focus your time reading just those mails. But the large volume magnifies the lack of feedback, the temporal aspect and the need to speed read.

Have you anything good to say about email? It's a great historical record. Most email tools have powerful search facilities. Sometimes this is useful.

Conclusion

If it's important to land your message and it usually is; first talk to some one directly or by phone. Use normal human communication to reach a conclusion and agreement easily and quickly. Then you can follow up with a short email with the decision you agreed so that they can search for it later!

Agile Gluttony

if you want to bring in Agile Software Development to your organisation because of:

1. you want to go faster
2. do more
3. do better
4. to save money
5. any combination of or all of the above

then you and your organisation is suffering from a serious case of Agile Gluttony.

If your primary motivation is any of the above you should really consider incremental process improvement in your current processes. I have seen on a few occasions, the first attempts at agile means a complete tearing up of the current process and the cutting out of nearly everything, except coding.

Unfortunately you can't go faster or save money by cutting corners. You can't do more by diverting everyone to coding tasks. You can't do better by delivering more code. When inevitably the organisation fails to meet the expectations the customer puts on it, there is great disappointment everywhere. The valley of despair for everyone, including the engineers, management and the customer, is a deep one.

There is only one reason to adopt agile software development processes. That is to satisfy your customers needs by the frequent delivery of working software. You care that your customer gets value. When you adopt agile for that reason, in the long term you succeed and reap the benefits. However the costs of putting in the necessary infrastructure and around your application and the coaching around your development teams that enable rapid and frequent deliveries will cost you a significant sum.

When you are able to frequently deliver working software to your customer; you don't need to go faster because you are perceived as responsive to their needs. You typically actually do less, harnessing benefits the old 80:20 rule¹. You will definitely do better because you deliver less change per release and your automated test suits catch bugs the customer had before. And you will save money by not doing the features the customer doesn't want or need.

---

1. The 80:20 rule states that 80% of the time a user will use 20% of an application features. The features in this 20% set, are the most important features and need to work well all the time. However we need to be aware they may not be the most valuable features. The most valuable features are the ones a customer is willing to pay us for.

Happy new year 2016

Welcome to 2016

It's a brand new year!

Recap

2015 was a great blogging year for me. I got to put down some of my thoughts on lots of things from Java, unit-tests, test coverage and aspects of teams. I set a target to write at least one article per month and I managed to achieve that. Just like 2014, I haven't published anything in November and December, but I have been gathering ideas...

Plan

So the plan for 2016 is more of the same. I want to continue to blog about software development. I'm currently in a management role, so my topics are going to swing more towards topics on managing and leading software development teams, with a small sprinkle of technical stuff, just to keep it interesting (for me!). The target, once again, is one blog entry per month. I'll definitely expand into topics such as code review and pair programming.

Java interview questions - level intermediate

This is the second in a series of articles on Java interview questions. These questions start to go into the details and differences of various parts of the language. Knowledge of them demonstrates a greater level of knowledge or experience than with the basics.

1. Are static variables inherited by subclasses?
   Static variables are inherited by sub classes. However are at class level instead of object level and there is just one.
2. Are static methods overridden by subclasses?
   That depends. If the reference used to store the object is of the super type, the super types static method is invoked. This is because static is at class level.
3. What is the difference between a Set and a List?
   In a set an object can only exist once. In a List the same object can be added many times.
4. Why should we use the @Override annotation?
   We should use this to ensure compile time checking that the contract of a subclass is not broken by changes to the superclass.
5. What is the main difference between Callable interface and Runnable interface?
   The main difference is that the call method on callable can return a typed result, that can be queried in the future. Callable also throws an exception.
6. Whats a covariant return?
   A covariant return is allowed since Java 1.5 and means that a method can return a sub classed object of the return type. In Java 1.4 and earlier the return type had to match exactly.
7. What is an instance initialisation block? An instance initialisation block is run once after a new object is created. There can be as many of them in the class as you like, but they run in order declared from top to bottom in the class.
8. Does an instance initialisation block run before or after the constructor?
   They run after the call to super, but before the rest of the constructor.
9. What is auto boxing?
   It's the ability in Java to automatically switch between the primitive type and the object, without a call to a converter method.
10. What is widening?
    It's the ability of Java to find a method with the smallest, closest java type. For example if one method takes a long and another takes an int, if I pass a short - java will automatically "widen" the short and select the method that taken an int.
11. What is the difference between "&&" and "&"?
    && is a short circuit logical AND, this means that if the LHS evaluates to false, the RHS will not be evaluated. In & both the left and right sides are evaluate every time. For || only if the LHS equates to false, then the RHS side evaluated. When | is used, both the LHS and RHS are always evaluated.
12. Dzone 20 things you should know about strings
13. What’s the difference between shallow and deep cloning

Update:25/04/2016

Software Oxymorons

An oxymoron is a construct that makes no sense because it joins together two terms that contradict one another. In this post we'll look at some you might come across in development projects. I'll grow this article over time. If you have any suggestions, please feel free to message me!

Oxymorons

• Refactoring Story - A story adds customer value, something tangible that the customer can appreciate. Refactoring is changing the implementation of a software system without the knowledge of the users or customers. So we can be either doing a story or refactoring.
• Refactoring Interfaces - An interface is part of the contract our software components and applications provide. Refactoring is changing the implementation without the knowledge of the users or customers. So if we change the contract, the users know about it. We can change interfaces or we can provide new interfaces but its not possible to refactor them.
• Object Oriented Database - these are a niche area of database theory that haven't really caught on in wider industry and they are also an oxymoron. Databases typically need to know a lot about our classes data structures in order to persist the data in a way that facilitates efficient storage and retrieval. Because of need to know the classes data structure, OODBMS break encapsulation, a key principle of object orientation. This places change restrictions and limitations on our software - something OO is supposed to help avoid

Definitions:

• Refactoring - Changing the implementation of a software system, without the knowledge of the users/components that depend on the software system.
• Story - Something that adds tangible customer value.
• Interface - The point of entry to a software system. Could be programatically ie like an Application Program Interface. It could be via the command line or via a Graphical system.
• Object Oriented - Objects are programming entities that exhibit the principles of abstraction, encapsulation, polymorphism and inheritance.
• Database - a software system that allows us to persist data to survive application restart, typically in tables, columns and rows. Columns are generally typed and can be indexed to facilitate faster querying.