5 things you can (not) expect from Agile

As the Agile Manifesto has entered its 15th year anniversary, it is not a doubt that Agility has crossed the chasm. However the late adopters, those who weren’t following the Agile movement since the early days, often do not know what to expect from Agility hence they are really unsure whether to jump on board with Agility. This is quite concerning because when you are looking into a new project management method you should know what to expect from it so that when you hire a large Agile consulting firm you know what you will get out of your investment.

I have narrowed down 5 major things you can expect from Agile that will hopefully help you gain confidence to transition towards Agility. There are other things that you can expect from Agile but I found that it is minor and can fall into these 5 major expectations.

1. Agile can be installed easily

Agile is a verb, it is something that you do, it is something that can be installed easily only by selected people in the company using mandate without any hard work because:

a. Agile is a software development methodology

Unlike Waterfall, Agile is a more modern software development methodology that gives much tighter control than Waterfall as the delivery cycle is shorter. Because it is a methodology, all you need to do is mandate everyone to do Agile by the book. If you found the prescriptions from any Agile textbooks are too vague or you can not find any solution for your context in any Agile textbooks, you can add additional techniques from traditional project management book like Project Management Body of Knowledge (PMBoK) until your Agile methodology becomes as close as possible to Waterfall and everybody in the company feel it is no different to Waterfall.

And because Agile is a methodology you only need to educate the Project Managers by sending them to 2-day Agile training. After the 2-day Agile training, you can expect Agile will be installed immediately by the Project Managers. You will see an immediate result after they have installed it.

b. Agile is a software

Agile is a software that can be installed. If you have installed software like JIRA, Trello, Pivotal Tracker, Version One or Rally in the company then you have made your company Agile. If you prescribe everyone, especially the coders, to update their work status in these software every day, you are Agile. Agile is about controlling coders’ work status every day using Agile project management software. If you are still using traditional project management software like Microsoft Project to control the project then you are not Agile.

Agile is about how heavy and how religious you are using the Agile project management software in the company. The more people in your company use these software, the more Agile you are. The more Agile software you use in the project, the more Agile you are. The best practices currently found in the industry are as followings:

• JIRA for tracking defects used by testers and coders.
• Rally or VersionOne for managing the Product Backlog used by Project or Program Managers, Business Analysts, End users and senior management.
• Trello or Pivotal Tracker for managing the Sprint Backlog used solely by coders.

To make things easier to understand for you, these software is a replacement for sticky notes on the physical board. But the extra advantages that you will get from these software is more control and more predictability because the software provides you with more metrics. These software also enables you to assign the work easily to the coders.

c. Agile is a collection of best practices

Agile is a collection of best practices because whatever Agile practices that work in another company will guarantee to work in your company too. The bigger the company that you follow their Agile practices, the higher the chance you will also become successful in Agility. If you install these best practices, e.g: by telling everyone to do standup meeting every morning, write requirements in User Stories format and use Agile project management software, then you are Agile. If you are using Gantt chart and Work Breakdown Structure (WBS) you are not Agile but if you are using Agile charts like Burndown chart and Cumulative Flow Diagram (CFD) you are Agile. The more Agile metrics and Agile charts you use in the project, the more Agile you are.

As you can see Agile is that easy. It is something that can easily be installed. It is as easy as installing an application on your mobile phone.

2. You don’t need to change a thing to be Agile

Because Agile is a thing that is installed in the company, you do not need to change anything in the company because when you install something it should not disrupt the whole company. What that means is you can still do whatever practices or techniques that you’re currently doing, e.g:

• assign tasks to each development team member.
• exhaustive planning and detailed requirements to ensure the project is predictable and does not run over-budget.
• ensure development team follow orders from the higher rank.
• working in silos to ensure segregation of duty and accountability in each team member.
• bureaucracies and hierarchical sign-offs to ensure the project is in control.
• using the current fixed-price contract.
• fixing scope to every Sprint/iteration and fixing the deadline to ensure the project is delivered on-scope, on-budget and on-time.
• measure developers productivity with predefined metrics that they never understand.
• appraise developers with existing performance appraisal approach to ensure they stay motivated throughout the project.
• turn estimates into a commitment to ensure developers are motivated and work hard.
• ask developers to do over time if they can not meet their Sprint commitment.
• treat developers as resources.

Basically, Agile is only a change of label from traditional project management methodology. You do not need to change the organisation behaviours and mindset down the road ever. This is because Agile is a set of newer terminologies for 21st-century project management that most of the times are confusing to the business people. As a guideline, the followings are the mappings from Agile project management terminologies to traditional project management terminologies.

• User story is a new way to write detailed requirements specification.
• Story points, whether the number you use is Fibonacci or T-shirt size, is a more complicated way to come up with the ideal time estimate.
• Development Team is a group of coders.
• Product Owner is Business Analyst who is responsible for writing detailed User Stories.
• Scrum Master is a new name for Project Manager who ensures that every Sprint the mandated fixed-scope is delivered by the coders.
• A Sprint is as a shortened Waterfall — the duration is not more than 30 days so management has more control in the project.
• Nothing needs to be changed every Sprint, you should do the same thing every Sprint to ensure the project delivery is predictable.
• Sprint Planning is a meeting where management dictates the development team how much work they should accomplish in one Sprint.
• Daily Scrum is a daily status update meeting for the Scrum Master and an opportunity to micromanage the coders.
• Sprint Review is a User Acceptance Test and sign-off session.
• Retrospective is a time for developers to play games and have some fun after spending so much time writing codes.

Because nothing needs to be changed in the company ever and because Agile is easy, you do not need to invest in hiring a professional Agile Coach to help your Agile transition because justifying the investment involved is too complicated.

3. You only need to change the IT department

But if you really want to change something to convince everyone in the company and your customers that you are really Agile, you only need to change the Information Technology (IT) department because Agile is an IT thing rather than a business thing. If you found that changing the whole IT department is too difficult because the people from Quality Assurance (QA) division or the Business Analysts don’t feel they are the problem then you can just change people from Software development division, with exception the people on the higher salary rank i.e: Project & Program Managers, Solution Architects, Delivery Managers, and Technical Leaders.

In Agile, Business Analysts do not need to change, Quality Assurance (QA) people can still do the same testing approaches, Sales & Marketing do not need to change, User Interface (UI) & User Experience (UX) designers can work separately from the development team and can still do Waterfall during design process, and Human Resource (HR) department can do whatever they are doing in terms of measuring coders productivity. This also means that the senior management does not need to change ever because they never contribute any problem during software delivery process. And even if the senior management changes their behaviours, the contribution of that behavioural change to company Agility is too small to be recognized and most of the time can be ignored.

If you really want to change something and make the company Agile, change the coders because they are the problem why software delivery in your company is so slow and why the software has very low quality and not according to customer expectations. Focus on changing the coders, the main problem in the company. The coders are the reason why your company is not adaptable and not competitive in the market. They are the reason why your company is not Agile.

Agile is a perfect tool for 21st-century managers to micromanage the coders and a perfect tool to ensure the coders work extra hard.

4. You don’t need to increase developers’ software engineering capability

When you plan to change the software developers, the main problem in your company, bear in mind that you do not need to invest any money to increase their capability in modern engineering practices. This is not an exception when you outsource the software development to developing countries in Asia. When you have an offshore development team, you do not need to invest any money to increase software developers skill sets and knowledge in modern engineering practices. Software developers can still write codes like in the Waterfall because Agile is mini-waterfall run iteratively with extra overhead meetings.

You do not need to invest any money in increasing software developers capability in modern engineering practices because they are in the lower pay grade than Project Managers and Business Analysts, not to mention they are more prone to resign from the company. In Agile, you only need to focus on upgrading Project Managers capability in managing the projects so that they know how to ensure software developers deliver the mandated scope consistently every iteration. Increasing Project Managers capability in managing Agile projects is crucial because Project Manager is the role who is responsible for project’s success.

Software developers do not need to know how to write automated tests like JUnit-tests, integration-tests, Cucumber tests, selenium tests and Coded-UI tests. Software developers do not need to know about Test first development techniques, code refactoring & clean code practices or even SOLID principles. They do not need to know how to do any of eXtreme Programming (XP) practices and any other modern engineering practices. Doing these practices only add the extra time that will make the project delivered later and adds extra frustration to the software developers.

The point is if your senior management does not understand it then you should not ever convince them to invest money in it because you can never justify the return on investments involved for these modern engineering practices. Agile is about being lean therefore the investment to transition to Agility should be as lean as possible and it is even better if you can make it as close as possible to zero investment.

5. You can still get the benefits from Waterfall

With all of the aforementioned expectations, you can also still get the benefits from Waterfall project. With Agile, you don’t have to lose all of the benefits from Waterfall because you can still have fixed scope and fixed deadline with fixed price. With Agile, it is even better because not only you can get fixed amount of scope for the entire project but you can also have a fix amount of scope delivered by the development team every Sprint/iterations. This scope delivered every iteration are high-quality features that can be used immediately by users in the production environment.

Not only you can get fixed amount of scope every iteration, with the same amount of scope the cost of software development will be cheaper than if you use Waterfall. With Agile, you will also have the opportunity to request for changes every iteration without sacrificing the features you requested early in the project and without adding any extra budget because in Agile change is free.

Does your senior management or your customers already know that they can expect these things when they are jumping on board with Agility? Perhaps one of the reasons why they are resistant with Agility is because they do not know what to expect from Agility. If they haven’t known anything about these things then I suggest you to share this article with them.

Are there any more things that your senior management and customers can expect from Agile that I haven’t mentioned but should be mentioned here? Tell me more by giving a response below and I will curate it for my next book. If it is reasonable, I will feature it in my book. Thank you for helping us improve the software development industry by spreading out the words about Agile. The software industry looks even better in the next 15 years when everybody know what they can expect from Agile.