Thoughts on SCRUM (in Perth, WA)

Last year I worked on a few SCRUM based projects in the Perth market. There were several challenges around the use of this software development approach, as outlined in this blog post. However, at the end of the day, the SCRUM approach was able to help us deliver some nice software solutions for our clients.

The good:

• Development can start sooner, as detailed specifications are not required. However, this also seems to be a downside as well (see "The Bad" points below).
• IT does not "overwhelm" business users with huge amounts of technical documentation. In my experience this type of documentation is generally either ignored or "skimmed-over" by business users (especially project sponsors).
• The Product Backlog is a great idea, as it removes a lot of the detail from the documentation and brings the terminology back (somewhat) to basic business requirement statements.

The bad:

• Clients need to understand that we cannot provide a detailed quote for the work up-front. In my opinion, this seems to be one of the major limitations with SCRUM (and its use within the client-base I have worked with).
• As we cannot provide a detailed specification up-front, scope becomes hard to lock down with the client. Coupled with the above point, client expectations can be hard to meet.

Don't get me wrong, I LOVE the SCRUM approach, but only in the right situations and for the right client. In the consulting space I have been working in, clients have often already been allocated a budget for the work BEFORE we get involved. The conversation then becomes (on the client end) ... "can I get the software built within the budget I have been allocated?". And that is where the SCRUM approach becomes challenging.

How do you work with SCRUM in this market? How does one say to a client "hey, we can't give you an up-front cost, we're not sure how long it's going to take and we need to work on a T&M bases until we complete the system". You can imagine the alarm bells ringing in the client's mind!

I don't have any really good answers. The approach that I now see myself taking is to use a top-down design, showing detailed screen mock-ups with business explanations of how they operate, along with several checkpoints throughout the project to review functionality with the client (referring back to the design for change request conversations). Business users can understand this type of approach and we can use this design to (somewhat) lock down the scope of the project and handle change with the client.

As I mentioned above, I love the SCRUM methodology and believe this is one of the best approaches to software development. But make sure you:

1. Understand it. Take the time to review all the material and maybe even get the certs (some excellent material at: http://www.scrumalliance.org/)
2. Educate your clients in its use. Set the expectations with the client up-front. Tell them how you intend to use this approach and what deliverables they will see, and how you will be managing change (from a project cost perspective).
3. Match the approach to the right clients. SCRUM is not an approach that can be used with all clients.

Goal Tracking

I have been meaning to get my Microsoft certifications for some months now, but work has always taken priority. This can be said for a number of things I have been meaning to do.

I noticed that there were more and more goal tracking websites popping up online, so I thought I'd give one of them a go. It was pretty crappy, so moved onto another. After a few I managed to find one that was pretty good. So, if anyone out there on the Inter-web would like to see what my goals are, and how I'm tracking, check out my GoalForIt profile. This is the best one I've found http://www.goalforit.com. 

Business Process Improvement & Business Intelligence

Gartner has just released a report that highlights the business and technology priorities for senior enterprise executives. The article can be found here.

Following on from my previous blog post, it's encouraging to see that business process improvement is sitting at the top of the CIO's priorities. What is also interesting is that this has been the top priority since the survey began in 2005. All I can say is that this is generally very different from my own experiences in the industry (with the handful of companies I have work with).

"Senior enterprise executives recognize that IT's contribution to economic performance extends beyond managing expenditures. They expect IT to play a role in reducing enterprise costs, not merely with cost cutting but by changing business processes, workforce practices and information use."

Gartner (http://www.gartner.com/it/page.jsp?id=855612)

The report also shows that Business Intelligence tops the list as well. This has always been a passion of mine, getting the right information in front of the right people at the right time. That can have a big impact on the success of a company.

I think these will be the key areas of focus for companies in the current financial climate. Doing "more with less", improving business processes and providing timely business intelligence to management will enable companies to become more efficient and survive the current market.

Good business process before software solutions

This post is about a pretty basic concept. However, based on my experience over the last couple of years, I've decided to blog about it anyway. 

Unfortunately I have seen several examples of companies that choose software solutions BEFORE reviewing their business processes. Remember that a bad process is still a bad process when it’s automated. When I step into an organisation and start asking questions about their business processes, it’s amazing how often answers to these questions are difficult to come by. Why? Well, the basic answer is that each individual/department has different processes to achieve the same outcome. Lively discussions then ensue to determine which of these processes to use going forward. At this point the software analysis should stop and business analysis should take over. However, all too often this does not happen.

This is a difficult situation, as there is no immediate benefit to reviewing the business processes within a company. Consider this: Management in a particular division have a problem they want fixed, that’s why IT is involved. Management has decided that if the problem is fixed, the division will become more efficient. So just blaze away and install or develop something that will automate process XYZ (or whatever their problem is). But what if this process is common across different areas of the business? Is it IT's job to identify this? Or upper management within the company? I think it's BOTH.

I have worked in large companies where the IT management has been astute enough to identify these common areas and articulate the benefits of business processes reviews to the board or CEO (CIO if one exists). But it’s something that we need to keep in mind as IT professionals.

As an IT consultant, keeping the following principles in mind will help this problem:

1. Understand the business and what will make life EASIER for the end-users.
2. Review the Business Processes and recommend improvements if required.
3. Understand what can be gained from an IT solution (try to get some idea of ROI) before proposing any IT solutions.

Remember, step one should ALWAYS be to get the business processes correct BEFORE talking about IT solutions. Don’t simply throw technology at a problem because there is some perception that it will magically fix it. Fit the technology to the business needs, not vice versa.

Bitstrips.com

In a desperate attempt to try and de-stress, I've been playing around with a site called BitStrips.com. Here's my very lame first attempt: