Wagile – Pronounced “Waa Gee Lee” – Blended Agile and Waterfall

We all hear a lot about Agile being the new and Waterfall being the old approach to software development.

So tongue firmly in cheek I am going to talk about those Agile projects that don’t quite cut off the ties with the old Waterfall.

What is known in the industry as Wagile.

Looking at Agile, we should have user stories for all the functionality required by the business. However sometimes it is just ends up with focus on one part of the functionality being done in  Agile mode while run of the mill ancillary items are handled in a more waterfall model.

I am not going to try and guess all the possible items that could somehow fall out of Agile into Waterfall but I am sure that you can think of a few. Most likely low risk candidates for Wagile is reporting – assuming that someone somewhere has identified all the fields that need to be captured and made available to the reports as part of the initial Agile development portion of the project.

So why does Wagile come about? Not everything can make it in the sprints so to keep the client happy, items are basically snuck in outside of the sprints using the Waterfall approach sometime under the support budget rather than the development budget.

Is this the wrong approach? No approach is wrong if it keeps the customer happy but don’t try to pass off your shop as 100% Agile if your are doing Wagile.

 

Take a pay cut for future benefits.

This week’s subject is on when to take a pay cut.

If you stay in the consulting world for long enough as a Business Analyst, eventually you will find your pay stagnates. It is like hitting a brick wall. If you keep hitting it hard enough, eventually you may break through but there are easier ways if you are willing to take a cut in salary for up to a year.

Why would you take a pay drop?

Let’s first look at the reason why you would not want to take a pay cut. If the job on offer is not going to benefit you in anyway – such as: closer location, new experience, work life balance, really need some cash – then walk away. If you can’t find any benefit then as soon as a better option comes along you will leave anyway and possibly burn a bridge in the process by your short stay.

As for the future benefit reasons to take a pay cut in the short term:

  1. Offers new experience that will make your more marketable to current trends.
  2. Closer to home so less time wasted on commute allowing you to build up skills, attend training after work. This also includes going part-time.

Point 1 – New Experience

As Business Analysts we are supposed to keep our eyes on trends in the market for our business clients. We need to also remember to do it for ourselves. This may mean as a Web Business Analyst you may need to take on a Mobile Project, as a Sales Business Process Analyst you may need to learn about Human Resources etc.. Search the job boards for your location and see what is in demand and aim to get experience in the subject.

Point 2 – Closer to home / Part-time

Anytime you can free up time that leaves the opportunity to expand your skills. The extra time can be used to start new personal projects, formal studies, make yourself available to other clients etc.. Expanding your skill set will ensure a future stable income.

Changing project approach does not mean a quicker delivery

Sometime clients are concerned about the progress of a project and look at ways to speed things up.

One way I would recommend extreme caution with, is changing project process after a project has started. Now don’t get me wrong in that this rule does not apply in all cases, as sometimes it does make sense to change. However, if the project is only for a few months, valuable weeks can be lost in the adjustment.

How do you know when to change?

Ask yourself the following questions:

  1. Is the current process so flawed that it will not meet the end of project objectives / goals?
  2. Is the project of long enough duration to allow for the ramp up time to adjust to the new process?
  3. Are my staff familiar with the new project approach?
  4. Has there been other projects that have used this approach in the past within my department?
  5. Are standards and training materials in place that will allow my staff to quickly adjust?

If you answer NO to any of the above questions, understand that this change in process may have a more negative impact than you allowed for.

Reminding Business to focus on the business need and not on the solution

A few years ago I was asked by a client to get on a plane to Florida to meet with some business partners and do a final business review of a requirements document that someone had put together.

When I arrived, the business partners present thought that in a few hours we would all be done reviewing the requirements document and then we could then spend time over the next 2.5 days discussing other items. After all they had spent several other sessions over the past few years developing the document so as far as they were concerned it was in a final state. That was until I came along.

The requirements document I had been asked to review had been written in the format of making business work around perceived constraints of IT. It had a good explanation of what the business were trying to do but not the actual business rules behind them. Instead the business had adjusted their rules to meet what they thought the IT department would require.

Two days after I arrived, we finally had a good working document that focused on the business rules and left it up to the IT experts to work out how to implement. Dozens of perceived technology constraints were removed from the document and the business eyes were opened up as to how an IT solution can help rather than hinder their business.

I see this time and time again, where less experienced Business Analysts allow focus of a requirements gathering session to end up bogged down into making Business Rules that tie in with supposed constraints on IT solutions. In turn this leads business to expect little out of IT because they don’t expect them to deliver a great solution. Worse still, the self imposed constraints mean that items that are not delivered from the bad requirements are considered of higher failure because the business compromised so much in writing the requirements.

As Business Analysts there are times when the focus of the solution should be constrained by IT up front but those situations should be clearly defined in the scope statement. When it comes to large Business opportunities, IT constraints should be limited, as the whole purpose is to enable the business to move forward and not hold them back by using out of date solutions.