Bootstrap Agile with Agile

If your organization is planning to roll out Agile processes, take it step by step starting from addressing the process issues in a priority manner just like you handle your customer projects. Let this knowledge and lessons flow from individual to individual and from team to team until at least the processes get stabilized. Let the teams be participative in the process improvements, and don’t try to force it hard, without reasoning, and don’t forget Agile principles here as well.

 

Collaborate People:

Collaborate with the team(s) in identifying and prioritizing the pain-points of the existing process. Suggested approach is to ask stakeholders from different roles and different experience levels to participate. This will bring the possible 360 degree view.

Be ‘specific’ about the problems and the proposed solutions. Don’t use text book statements. For example, ‘Follow iterative development model’ maybe too generic solution but identifying ‘What exactly would be the deliverables’ with an iteration's code drop and ‘How should we be following up with the customer’ will be specific.

Process the Feedback:
What is that you implemented right?
What can be done better?

Let the lessons (good and bad) be shared across the iindividuals and the teams.


User Stories:
As a Developer, what is working for me and what is not working for me?
As a QA Engineer, I feel I need these requirements.
As a Project Manager, here are the issues that I would like to address.
…

Take out the Waste:

 The whole purpose of Agile is about minimizing the rework and waste and maximizing the productivity. So, implement only those principles of Agile that your team really needs. What worked for the other organizations and the teams may not be the same as what your team needs.

Example: If you don’t really need burn-down charts, don’t use them. If User Stories do not make any sense to your specific project, keep them aside. It is not just about spending time on things-of-no-use  but you are loosing time to be spent things-of-use.

Ask this simple question, “Is this method making my team do better or worse?”. Betterment is not always about doing new things. It maybe about not doing the things that-are-not-worth-doing i.e., taking out the waste.

To summarize, consider your process change also like a mini project, sticking to the basic Agile principles, processing the feedback with continuous attention with proper team collaboration. Things will fall in place in a matter of a few weeks. We may call this ‘Bootstrapping Agile with Agile’.

A process that is organically evolved would always carry more value than a process that is purely taught. As much as possible, try not to be biased by the name of the process but focus on the Goals that you need to achieve from the process that serves the interests of all the stakeholders.

 

 

What 'exactly' are the issues that you would like to solve with Agile?

What are the 'root causes' of these issues (not symptoms) so that you can plan implementing Agile from the roots? Remember it should not become yet another process.


"Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net"

"Is Everything Alright?” may not be Alright

Incremental deliveries are not just good enough. You should ensure that they are really adding up to the Constructive feedback in achieving your long-term goals, than just aiming for "Everything is Alright" with every incremental delivery.

---

When our team first started with the Iterative model of development, the information we used to exchange with the customer, used to be something like this:

• Implemented ABC, XYZ, … features
• Fixed the Bugs: XXXX, YYYY, ….
• …

(X) In the follow-up calls with the customer, we used to ask very generic questions like “Is Everything Alright?” OR “Are there any issues?” and we would be eager to hear from the customer side “Okay, everything is just perfect”. We didn’t use to pay enough attention to ‘How they were/should be testing the deliveries'. Often, we used to have a demo, but one cannot cover everything in a demo.

The customer came back much later in the project cycle reporting a few serious bugs which should have, ideally, been reported before. They cost us more considering the amount of refactoring and the other overhead (planning, prioritizing, additional testing etc.) required. This meant that the iterative development didn’t completely serve its purpose, though it made a few things better in handling the project internally.

---

It took us sometime before we realized a few facts:

• ‘Incremental Deliveries Are Not Just Good Enough’ and we need to do everything right to ensure the customer would be testing those deliverables diligently in providing the Right feedback at the Right time.
• Don’t even aim for “All is Well” reply from the customer in the beginning cycles of the project. It is not something to cheer upon. You should welcome Specific and Tangible feedback and Rework but don’t try to avoid it. Anyways you would be working on it later and you cannot escape from it.
• Also, we became conscious about the addendum information that we had to deliver along with the incremental deliveries.

-Demo

-Exact list of Testcases (Acceptance Tests); Scenarios that the customer can explore.

-What's Pending (Something for which you delivered a temporary or an incomplete solution) and ‘Known Failures’

-'In Process’ user documentation, if any

-Any other useful notes, that is not taught by your Agile coach but contextual.

• Welcome those short-term hits for the long-term Quality goals.

• Communicate ‘What has to be Tested’ along with ‘What is Added and Fixed’ because ‘the later a bug is caught, the costlier it is’.
• ‘You test it Now’ is more practical than ‘You should have reported it before’.
  
  

When your requirements are highly unstable and volatile, use the incremental deliveries as artifacts to decide the direction you need to travel than just an instrument to validate what was done. This simple perception change brings in a lot of difference in your approach and methods you follow to receive the feedback. The same might be applicable, but to a lesser degree, in the scenarios where your requirements are fairly stable.

"Remember that the incremental deliveries are, in general, the production quality code drops and not miniature or prototype versions". So, even the validation has to be done on the similar lines. 

Sometimes, it is important to know ‘who would be testing your deliveries from the customer side’. It would be very useful getting in direct contact with them rather than getting the second-hand information from someone who is working with you on the requirements and estimations etc.. This will help process the information better and faster.




Are you ensuring that your incremental code drops being tested diligently from the customer side?

Are you talking to the right person from the customer side who is validating your deliveries?

Is the feedback you are receiving ‘Specific and Constructive’?



(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Is Agile limited to Development projects?

Can we practice Agile in a maintenance project?
Can we follow Agile in executing a migration project?
Can we use Agile in …?
...
Is Agile limited to only development projects?

What drives us to adapt to a new process or alter an existing process? It is always this golden objective - Quality. Different projects carry different Quality criteria. Before trying to find an answer for “How do we deliver Quality in this project?”, we need to answer “What does Quality mean for this project?”

Let me try to illustrate this with an example of how we implemented Agile in a Production Support project.

---

*A quick background of the project:

• The project was about handling the business-critical Production Support for a telecom client. This was handled offshore completely.
• The customer’s business was tied up with different Service Partners to provide end-to-end service to their customers. Taking this to technical terminology, it was all integrated on an SOA based architecture.
• Often there were service failures due to various Technical and Operational reasons and our job was to analyze those failures and handle them offline.

*So, what was Quality meant for this project?

• Reliability - As we worked on the production issues, it was a MUST that our solutions were highly Reliable.
• Better and Faster - It was DESIRED that we provide continuously better and faster solutions, considering the huge customer-base of our customer.
• Timely & Consistent communication with the business users - We had to work with the onsite team, working on the other side of the globe. So, our communication with them had to be -
  • Timely - Delays, due to timezone differences, should be minimized so that end-customer concerns are addressed at the soonest. Not a typical requirement in Development projects.
  • Consistent - Our communication with the onsite team should always reflect that either we know something or don't know something as a Team but not as Individuals. It is highly DESIRED from business point of view.

• Continuous Learning of the System: It was a complex system and so it was DESIRED that we learn the system better and better as we go dealing with various issues.
• Customer satisfaction through End-Customer satisfaction: "Our customer will be happy, if their customers are happy". This is the simple business rule that we always respected.

*So, how did we implement Agile here?

The daily Scrum meetings played a major role here and this is how we tuned our Scrum approach in dealing the issues reported by the end-customers.

• What is New (Either we didn’t handle this before or this is slightly different from what we handled before)?

Can we handle this ourselves? If so, who is the best person to handle or help? Or, do we need to approach the onsite team? (Providing ‘Reliable’ solutions)

This is towards the “Reliability” criteria.

• Are there any Bulk (High in number) and Repeated (being seen more often) issues?

This is towards identifying the need for building new tools or modifying the existing tools (Automated or Semi-Automated) to meet “Better and Faster” criteria.

• Any escalations?

Business SLAs take priority over having a perfect solution (‘End-Customer satisfaction’).

-- Timely communication with the onsite team and continuous learning of the customer’s business were the by-products of these discussions.

-- It also helped us address the Single-Point-Of-Failures (SPOF here is Knowledge being confined to individuals). SPOF would, in general, have more impact in a Production environment than in a Development environment.

-- We never discussed the issues that were routine and they were far off the Scrum meetings. Our meetings intended to be meaningful and action-oriented. We didn’t make them daily status meetings. Our team was enabled to take care of the routine issues by themselves.

---

What is meant to be conveyed through this example?

-- Challenges are different for different projects. Some projects would be more about ‘What to Implement’  whereas some projects would be more about ‘How to Implement’?

-- Our project was more about ‘What to Implement’ than 'How to Implement’. I must say that technologically it was not so challenging but we were constantly identifying and implementing the tools(Java/J2EE and PL/SQL based - just to add) that create value for the customer's business. So, it was more of a business challenge.

-- There was no concept of continuous delivery, iterative development, early feedback etc. in this particular customer engagement. From a different sense, our solutions were reaching to the customer on a daily basis (unlike in a typical Development project).

-- To state the fact, it took us some time to figure out what exactly were the expectations and the Quality criteria. Every project would see this phase, particularly when your team is handling a new type of project. Some conscious experiments and trial-and-errors are required to get on to the right track.

The subtle message that is intended to be conveyed is - ‘Work on identifying your Quality goals and customize your practices to achieve those goals’.

What are the Quality objectives of your project? How is it different from the other projects that you executed?
How can you apply the tools(practices) available for the job-in-hand? What works for you, and what does not work for you?


(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Project Tracking Tools in Agile

This is a big question that most of us come across once we start dealing with "How to Implement Agile". Do we really need tools that are made for Agile? Is it about the principles or is it about the tools?

First off, Agile practices emphasize more on "Getting the work done" over "Following Process" - so it looks like no tool is required for the task management and whiteboard and story cards kind of approach is good enough.

On the other hand, you need to answer very basic questions at any given point of time, to anyone from any location.
- How many tasks (Backlog) are pending?
- Who is working on what?
- How many bugs need to fixed?
- What are the tasks being worked for this iteration?

Assume these questions are being asked from a project stakeholder from a different site; we can't show him the Task Whiteboard or send a snapshot of that on a daily basis. It is impractical.

So, maintaining the balance - "Not deviating from the Agile principles" and at the same time "Respecting the interests of all the stake holders including the execution team" - we need a tool which has a simple "search", "categorization" and "prioritization" capabilities.

Here is an example of what we used to do for project tracking purposes:

-- Someone from the team used to make a TODO list from our daily meetings or Sprint meetings. He need not be the Scrum Master and we actually rotated this job among the team members.

-- Rotating this job also helped in creating more "participation" and "sense of ownership" among the team and the team used to get more understanding of tasks beyond their ownership.

-- After the meeting, the person who made the TODO list, would create Tasks and Bugs on a Bug Management tool (We used Bugzilla). Tasks are the new development (Bugzilla has support for Tasks) work. The Tasks and Bugs on Bugzilla looked like this.
-----------[Task] [Login][Implement Basic Login]
-----------[Task] [Login][Implement Forgot Password]
-----------[P1] [Registration][Fix UserId validations]
-----------[P2] [...][............................]
[You may think of other practices like using user-derived standard prefixes for a bug's subject line, use of Keywords etc. for categorizing the work based on Functionality or Iteration basis. The idea is to find out what is already available and how you can make use of that to fit in your requirement.]

-- This would not take more than a few minutes and the SCRUM master (or the Project Manager, whatever the title is) also used to sit with the engineer who is creating the task to guide them better and it also used to help them as "undocumented" mentoring process.

-- We used to assign a default priority P5 for all the Bugs (including tasks) and assign P1 for the Tasks/Bugs for this iteration. Also, P2 priority was used for those tasks/bugs that were planned to be handled in the current iteration but could be pushed to the next iteration should the time did not permit. This was for handling the priority within the iterations.

-- This helped everyone being in sync with the task management. Also, there used to be minimal duplication of work - like using some tool for the Project Management and some other tool for the Bug Management and manually transferring information from one to another.

-- Even for the project stake holders from different sites as well, they can simply run the "Saved Queries" to get the information they need. Remember you need to have different "Saved Queries" to serve the purpose of different stake holders and it is one time job. Some of the "Saved Queries" that I can list from the top of my head:

--- Tasks/Bugs for the Current Iteration

--- Tasks/Bugs for the Previous Iterations (Copy & Paste job with the Iteration name being the variable)

--- PENDING: Backlog (Same as above but no Iteration tag/keyword assigned)

--- DONE: Overall Tasks/Bugs already closed

--- OPEN: Tasks/Bugs being worked on

--- <Any other queries that we used on a routine basis would go here>

-- The same queries were used even on the project Wiki pages as pointers.

-- It also helped any quick review meetings at any time and from any place.

-- Beyond that it worked as a good engineering practice to integrate SCM tool (for Bug Reviews and Tracking Regressions etc.) as well because you are tying up a Bug Number. (We integrated Bugzilla with SCM).

This was a "good enough" and "a derived" approach for us with the Questions we needed to answer in the project management. Again, this was the solution that worked for the requirements we had and mention of Bugzilla here is just to state an example. What we need to take into account is - thinking beyond the bookish approach and having a simple process in place to answer the basic Task Management requirements for "serving the individual stakeholder requirements" and at the same time "ensuring the sustained development".

"No Process" and "Over Process" both are equally dangerous. Improvising your processes does not mean doing everything new and deploying new tools.

Have you charted down your project tracking requirements (what exactly you want) before zeroing down on any tool?

Has your team been involved in evaluating the project tracking requirements? Are you ensuring that the 'team collaboration' principle is used in developing the project tracking process OR reviewing the existing process whatever the case maybe?

Have you evaluated if the existing in-house tools can be tailored to meet your requirements before investing your time and money on a wholesale new tool?

Is your project tracking tool or methodology adding to the "Simplicity" principle of Agile than adding more "Complexity"?

Overall, Are you inviting the feedback of the team to ensure this process also evolves better (iteration by iteration) as you progress? (Just like we talk BIG about evolutionary requirements and evolutionary design)

"Simplicity of Agile should not be lost in the complexity of Tools"


(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Business principles are not tightly coupled to any industry

As you have probably started thinking, the poster is not from any IT office. This is a poster I've found in a restaurant that I've recently been to. Well, I'm not going to write anything here explaining those principles. You are the boss of your own and you are the best person to explain those principles to yourself on the grounds of "What makes sense to you" and "What adds value to you and your team" at work.

"Values of an organization should reflect strongly in its processes"