Randy Rayess
In this week’s edition of Expert’s Thought on Agile Project Management, we are in conversation with Kannan Subbiah, Agile Thought Leader and CTO, MF Utilities. Let’s read what Kannan has to say about agile methodology and its impact on managing teams.
- Kannan, please tell us something about your organization and where it stands in terms of committing to Agile.
MF Utilities is a start-up venture. We have adopted a mix of both traditional and Agile practices as we have certain constraints in completely going the Agile path. We however don’t have a choice to ignore Agile, as being able to take the changes to the market quickly is the key thing to succeed. The Agile experience that I share here are not necessarily that with MF Utilities, but include my experience with my previous employers.
- We would love to get insight into understanding your journey with Agile Development?
With the legacy / traditional approach, the business analysts took many months or even years to come up with the requirements specification document which runs into few hundreds of pages and by then so much of money and efforts are already spent with the design and development yet to be started. The problems faced with this approach were many and some are listed below:
- The designers and developers find it very hard to read through the huge specification document and digest it to be able to accurately translate the same into the design and architecture for a working system.
- Understanding was all the more difficult as some of the key contributors to the document would not be around for the necessary knowledge transfer to the design and development teams.
- The design and development team was sitting thousands of miles away in India, solely depending on calls to discuss on.
- Above all, a year is too much for the business to stay put and there were far more changes in the business practices, leaving the requirements specification almost a legacy.
Agile methodologies are expected to solve the above problems and that’s when we have started our Agile journey.
- As your company grew, how did you manage to maintain the values and culture?
The agile culture is far more different than the traditional approach. In a sense, Agile depends largely on the culture than the process. As always, culture change is the most difficult to drive in any organization. The Agile requires agility in everything, which includes, the expertise of the team members in their specific areas, team and collaboration skills, communication skills and above all the attitude to accept changes.
Of the above, accepting change was a hardest thing to digest amongst the developers. But they needed to be educated that change coming in early on is far better than the changes coming in at the later stage of the project. Changes identified early on makes it easy for all the stakeholders. Such changes will be fresh in their mind and the information can be shared up to the developers without much loss of details.
But the challenge of embracing the change still remained, as some changes have impact on the product architecture, making the change complex.This requires the architects and designers of the product to get the foundation right, so that the architecture becomes scalable, both vertically and horizontally and thus making it easier to implement changes. Every member of the project need to have the attitude of expecting a change in every thing and design & build the product accordingly.
The Architects had the biggest challenge, as they had to have a holistic view of the product and just not the current user stories being discussed. While they don’t need a detailed specification, what they needed was a blueprint of the business processes that is being automated, so that they can visualize how the smaller user stories are going to fit into the overall product architecture and what are the other dependent processes.What they also needed to consider was the unstated requirements that might come in any time.
Documentation is another thing that made the difference. For developers, it was easy as they just needed to focus on the much smaller user stories every time when they take up a task, whereas the business and process analysts found it challenging to get a complete view. Usage of tools to generate the documents from the work product, i.e, the source code itself is a better option, as the content within the code is actively maintained in line with the code changes.
- What is your view on Project Management?
Managing Agile project was a bit different,as the PM or the Scrum Master now had to necessarily split the tasks into far smaller so that the biggest task would take less than 20 or at the most 40 person hours. All the more difficult is to get the right representation of the end users in the standup meetings.
Yes, this was difficult, as most of the times, the business analysts representing the business users were not truly reflecting the needs of the end users, resulting in the users finding the product not meeting their needs.
Leave alone Agile, in my view, the Project Management team shall ensure that the project is on course to deliver the intended value. This evaluation should happen more frequently and the Project Manager shall enable the stakeholders to take decisions on re-prioritizing the project, program or even suspending or winding down the project if the value delivery could not be established by continuing with the project.
Picking the right team members with the right skills and assigning the right task to get the best out of every member is always a challenge for the Project Manager.
- Where are Agile teams currently going wrong?
Most still think that Agile is a product, which can be just plugged in and the benefits are seen, which is wrong. Thanks to more and more Agile failures, now the teams are getting to know more about Agile and it is being understood as a culture.
The other thing the agile teams miss out is on automation, making the change implementation easier and thus reducing the change implementation time. The areas of automation that are necessary and cannot be ignored are the unit testing, build automation and continuous delivery.
On the same lines, the developers should be educated to do a continuous code refactoring, so that the every time a change is implemented, the code improves and makes change implementation a breeze. This as I have seen is one of the most ignored area, which, when ignored, makes the code legacy sooner.
- One of the biggest project management challenges is dealing with risk. How do you handle this?
Risk directly impacts the value delivery of the project or program. Agile approach in a way makes the risk identification and management a bit easier than the traditional approach. When done well Agile practices, eliminate or mitigate the risks like, scope creep, personnel, design / architecture risks, etc.
The active participation by all the stakeholders, which is essential for Agile, makes the risk management a lot more effective. But it is not without any challenges. The following are the challenges around risk management:
Risk education was a challenge. The team members as such are working on sprints with focus and dedication, who would always claim that they don’t have time to spare for identification and assessment of risks. As such identifying a risk owner is a challenge.
Finding the competent resources for the Agile Project is always a challenge, though this is partly mitigated by employing the pair programming approach.
Certain risks, which are not noticeable at the user story / sprint level, but at the product level goes unnoticed or such risks does not get much attention in the daily standup meeting or even in the retrospects.
- Can you give us some suggestions on how agile team should plan their tasks better?
Follow the the right combination of continuous engineering practices, like Behavior Driven Development (BDD), Continuous Integration (CI), Test Driven Development (TDD), etc. These practices when done well reduces the feedback cycles and thus increasing the chances of acceptance of the delivery and thereby ensuring the realization of the expected value.
Keep a tab on the right technical strategy and platform for the product, so that it gives room for accommodating architecture spikes (need to change the product architecture to accommodate a change) easier. This approach will help greatly reducing the technical risk and thus improving the scalability of the platform.
Don’t defer the security implementation to the end. Make the security and privacy requirements part and parcel of each of the user stories and educate the team members to embed secure coding and design practices as part of their daily routine.
- You are obsessed with being productive all the time. Can you give us some tips on productivity?
Prioritization is the key aspect of being productive. Develop the ability to assess the priority of the tasks on hand and focus on closing high priority tasks and the dependent tasks.
The other aspect of being productive is being a team player and a team builder. Your team needs the right mentor for them to exceed your expectation and you be the mentor. Share knowledge, win their trust, and be with them to let them succeed. And their success will be your success.
Would you like to share your thoughts on agile method with the community? Write to us at[email protected] and we’ll schedule an interview for you.
Learn more about agile development with VenturePact’s latest Ebook.
[hs_action id=”5639″]
