Any development project leads to maintenance at some point. It is very natural and expected as customers start using the software over a period of time. A scrum team having done several successful development sprints finds it really challenging to adapt such a change. Some of the challenges are:

• Rapidly changing release dates and priority.
• More flexibility and responsiveness is expected from the team.
• Team requires a different kind of thought process as it involves a lot of analysis, for instance to reproduce customer reported issue, dig deep into the existing code base to identify flaw in the code and then eventually put a fix in place.
• Team communication with customers or Product Owner also is a challenge, as you may require his/her help to reproduce a scenario and also assistance during the analysis.
• Sprint goals can vary. As maintenance sprint would also require to address ad-hoc emergency bug fixes and testing.
• Code quality and some other practices like code review generally takes a back seat

and the list goes on….The question arises, Is scrum or agile a best fit for maintenance or legacy projects?

The answer is YES!!!. Why? Because, the primary purpose of agility is to help the team handle lots of uncertainty, adapt to change, shorter release cycles, production ready software. These attributes are more essential and makes more sense (or equal) when a team is doing a maintenance sprint than a development sprint.

Some techniques that I found to be very effective for maintenance sprints are:

• Maintenance bucket: Allocate a percentage of sprint capacity of the team for addressing maintenance issues. This will ensure that the other sprint goals not related to maintenance are intact. A Product Owner can choose the percentage depending on the number of issues that the customer reports and application stability. This makes more sense when team is focusing both on development and maintenance stories in same sprint.
• Just enough Refactoring – Ensure that every possible opportunity is utilized to refactor the code as you touch the legacy code. This is possibly the best phase to reduce the technical debt.
• Automate bugs - Often you’ll see that the customer reported issues shows up more than once. Developer usually blames the lack of quality code, unit tests and so on. Automating fixed scenarios will ensure that you don’t see them again. Its not the only and the best solution, but, fits best when you don’t have time to refactor/redesign code to make it more unit testable.
• Development sprints should have a focus on reducing technical debt – Its very difficult to always focus on step 2. because teams usually do not have enough time to refactor code when customers are waiting for a fix. Team also don’t refactor because they are afraid of making mistakes. A wise approach in such situations would be to allocate time in every development sprint to add more stability factor into the code. Refactor Incrementally!!
• Collaboration and communication with Product Owner and customers – Its strange, but true. Working closely with PO and customer is more essential during maintenance sprints than probably required during development sprints. This is because team has to be on top of things to do adequate analysis, team has to understand the customer usage scenarios, reproducing the problem, understand the context in which the old code was written and providing solutions.

To summarize, A maintenance sprint can be hard to stick to practices and process that the team has been following in development sprints. However, Agile methods if applied as discussed, team will be able to leverage its benefits and perform well.

Being a good product owner is not easy. It is one of the single point of failures in agile enterprises. Being a product owner in a distributed setting has some extra challenges. We have put down the qualities we value in the product owners that we work with and have thus created a picture of a great product owner. Being a great product owner in a distributed setting means that you should be:

1) Available and approachable: It should be easy for the team to reach the PO when needed. Usually, POs have other responsibilities too within the organization. He should make sure that he has enough time available for the team.

2) Knowledgeable about the product: A PO must have a good knowledge about the product/project that the team is working on. He should be able to answer most of team’s questions instantly without having to ask someone else.  He should also be able to judge what the customers want and prioritize the features accordingly. He should be a hands on person, so that he can give timely feedback to team about the things developed.

3) Knowledgeable about the organization structure and able to manage the internal stakeholders: The PO should know his organization well. He should know who to approach for solving different kinds of impediments.  This is vital for the team because, it relies on the PO to guide them through the organization structure and to manage stake holders. It helps if the PO also has a degree of authority, so that he can make certain decisions that can help the team/project.

4) Knowledge about Scrum: The PO must know and follow the principles of Scrum. Write good user stories, keep the backlog tidy and prioritized. He should be able to say ‘No’ to his stakeholders when random ad-hoc requests are made. In that sense he protects the teams from interruptions.

5) A team player: The PO plays the most important role in a Scrum team. The team does not work for the PO, the PO does not work for the team. They work together as a team. This realization is vital for the PO and for the team to have a fruitful long-standing engagement. It helps build trust between PO and the team. At times, the PO should also inspire the team with his vision about the product. We have worked with a great number of POs who love to interact with people, want to know what motivates them and love to spend time with them.

6) A straight shooter: The PO should give honest and straightforward feedback to the team whenever needed. Don’t wait, don’t sugarcoat it, just say it. It’ll help the team avoid doing things which do not add value.

7) A good communicator: He should be comfortable/fluent with English. He should be able to convey his ideas clearly.

——

This article is based on inputs from Vikram Kapoor, Prajeesh Pratap and Sachin Satyappanavar

In my previous post, I talked about what can Scrum do for Developers (team members). Today, lets talk about Managers. I’m taking about delivery managers, project/product managers etc. Generally, people who manage people who make software.

Managers crave for Commitment. They would like their people to actively make commitments and work on them. In Scrum, the team makes a commitment each sprint. Everyone in the team strives for this common goal. They self-organize, kill impediments and generally do whatever it takes to meet the commitment. Usually, after the initial few sprints, the teams will start meeting their sprint objectives fairly regularly. Team members prod and inspire each other throughout the sprint to keep everyone moving towards the goal. The manager can just sit back, relax and watch! (a fairy-tale, isn’t it?). Well, not really, a manager will be called into action to resolve some impediments and problems that are out of team’s hands. Scrum teams are better positioned and equipped to manage their commitments, taking at least some load off the managers shoulder. So, rejoice!

But the manager’s boss will hold him accountable for getting things done (or blame him otherwise). Generally, managers don’t really work on making software, they rely on other people. Which may make them feel out of control, and they may start micro-managing the team or bothering them every few hours for updates! (“to stay on top of things”). Scrum addresses a lot of these issues. First of, the manager gets better predictability based on team’s velocity. It gives a fairly good indication of how much the team can do in future sprints. And with with daily scrum, sprint BurnDown, sprint review and release BurnUp, you can stay on top of things without having to ask for it.

I’ve saved the best one for last: Teamwork. If you do Scrum right, your team will work like the Avengers! Well, almost. The common sprint goal gives the team members a sense of purpose. They will set aside their differences. They will figure out who’s best suited for what, how to bring everyone to that level; they will coach each other, critic each other and support each other. They will work with each others’ strengths, and work around (and eventually improve) the weaknesses. Just like the Avengers! (you see?!)

We had a hierarchical structure with my previous employer. The project manager, apart from taking care of project related activities, was also responsible to oversee people issues. These conversations used to start with “Can I talk to you?”

People issues such as someone is not getting well with the team, consistently not present for some key meetings, not spending required number of hours in office or not being productive during work hours or staying late consistently or not effective at work and so on and so forth.

So, in Scrum world, how do we deal with people problems? Who is responsible to help the individual? Simple answer is “The team”. It’s easier said than done. At times, it’s difficult to have these conversations; especially if not all team members are matured.

This is when team should make some agreements with each other very explicitly. Create a structure within the team where they can give and share their inputs openly and accept feedback with an open mind.

This is what I propose for it.

1. Team should define what is important to them. It can be values such as

• Client Success
• Punctual
• Committed
• Focus only on work during core work hours
• Proactive

2. Identify the agreeable way to give and ask for ad-hoc feedback on these values
3. Define a structure where each team member is evaluated by rest of the team.
4. Identify how someone can get help or lend help to others.

When you start to solve a problem in TDD, one of the questions that most of the developers have is about the correct place to start testing the code.

Is it better to start with a high level functional test (Outside-In) at a user story and drill down into the low level tests as you  progress or to come with an initial low level design and then start writing tests from the lowest component (Inside-Out) in the design and progress to the higher level components?

A short answer would be that it depends on your / team’s coding preference or approach.

If you’re not sure how your code should look like or how it will interact or communicate with other parts of your system, it’s better to have a small design discussion with the team to identify the best possible design solution and start with the low level component and let it evolve as you write more tests.

But if your design already exists (Layered approach, where the layered components are identified like controllers, services, repositories etc.), you can start with the Outside-In approach.

As you see, Inside out testing implies a developer would probably consider the high-level design and break them up into low level components that interact with each other to provide the desired functionality. The developer thinks about how each component will be used by its client components and tests accordingly.

The advantage is that the team can deliver working software quickly as they have started with a proper design in his mind. However, since the code delivered was not written considering the high level user requirements, it may produce code that doesn’t go well with the YAGNI principle and also have a risk of not meeting the actual functionality.

In the Outside In approach, the part of system that has the closest correlation to the user requirements are tested first, guarantees that the critical parts of the application is tested first. Here the focus is more on how the user interacts with the system, rather than how the components interact with each other. The test cases generated hence supports the usability of the system.

Yes, that’s right. Agile teams don’t need software programmers, they need software developers. I don’t mean this as some English vocabulary usage. I think the key difference is, if you ask a programmer to build some code, you will get code. If that programmer is good, you might get good, reasonably commented and reasonably efficient code which works.

If you ask a software developer to build some code, you will first get questions before you get a solution.

• How does it fit in the business process? Are the requirements thought out?
• Are you sure you understand what it will cost?
• Who will support it? What about diagnostics and instrumentation?
• What kind of documentation will it need?
• How might it interact with other code?
• What platform will it run on. Are the scalability issues?
• How might it impact future development? How might it be enhanced in the future?

Another key difference is, programmers focus on languages, software developers focus on language characteristics. A programmer might see himself/herself as a Java programmer, C# programmer or a Ruby programmer. But a developer focuses on language characteristics such as strong or loosely typed? Object oriented or functional? Interpreted or compiled? Etc. This allows developers to quickly adapt and pick up new languages and technologies.

So, the key mantra for agile teams is to deliver high business value software with high quality. This cannot happen with programmers whose focus is just to code and ignore everything else.

Code is not always ‘THE’ solution but its ‘a’ solution.

Credit: This blog is inspired by a talk from Dan Appleman

I assume you have a better understand of Agile than this.

With that assumption,  I’ll give my view of Agile.

I believe to be effective with agile testing or to be a good agile team we need following

1. Agile mindset for People
2. Agile Practices in Process
3. Agile lifecycle Tools

So what’s agile mindset means?

−      Collaboration

−      Trust & Transparency

−      Flexibility in roles and responsibilities

−      Responding to change

In an Agile environment, collaboration becomes a necessity rather than nice-to-have. Collective ownership enables self organized teams. Dev/test separation not always present – quality is a team responsibility – not just testers.

So what about Process and Practices?

Testing is a not a separate phase in an Agile process. From day 1, developers and testers work together. Test early and often – continuous build, continuous integration and continuous deployment

The focus is on collaboration, including collaboration with the customer and making sure all team members understand the user stories and change them, as needed.

Some of the practices for agile testers are

−      Stand up meetings

−      User story reviews

−      ATDD/BDD

−      Team design reviews

−      Pair testing

−      Exploratory testing

I know its too much information to put in one blow. But I wanted to give an overall view of my thoughts. I’ll try to take a deep dive into each of these in coming blogs.

In the article below I share my experiences on what are the challenges an organisation comes across when changing software development model from Waterfall to Agile.

Large or medium sized software companies doing software development using waterfall for decades, today, find it challenging and extremely difficult to adjust their software development strategies and processes. The  software development management  primarily faces three key challenges:

What is a Sprint Review/Demo Meeting ?

- highly productive feedback loop that enhances your Scrum Team

- It makes the progress of the team transparent ( to management, stakeholders, to other teams and themselves)

- A chance to show what they have achieved and a forum to celebrate their accomplishments

- Tick of things which are done.

Why should the Sprint Demo be awesome??

- Touch Point with your customer – They remember this and most of the time determine how things are based on this interaction and the results of this discussion.

- Moreover, this is what the team worked hard for a complete sprint to achieve, this is “The Moment” to showcase your efforts and get feedback and improve on the product at hand.

Does/Dont’s for Sprint Demo :

- More than just a demo

- Ensure that you have invited the right stakeholders (involving the PO)

- There should be an agenda – Demo Script

- Demo Setup – Up and Running ( As agreed, consistent. Not demo apart from the demo environment)

- Environment – Bright lit and not boring and dark

- Energy is very important, the person giving the demo should be aware that he is demonstrating every body’s work in the team, the energy should reflect in the demo.

- Interesting and a bit informal ( depending on audience)

- Ensure that it is visible to all in the meeting

- Do it from a single machine/location.

- Be available ( not someone walking in after the demo starts).

- Keep your mobiles (silent),other sources of disturbances at bay

- Prepare for this Interaction (it should be “Great”) and “No surprises” – Pre-demo. Create Relevant test data, if the story has no visible UI provide relevant tests. Don’t skip them.

- Time Box it 1-2 hour for a team of 4-5 professionals ( 2 Week Sprint)

- Have an introduction from the Product Owner on the Sprint Goals – on what to expect for the stakeholders

- Inform everyone: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?

- Use your best communicators for the sprint demos.

- Welcome all feedback, make a note of the same ( any team member) and sent it back to the PO and stakeholders

- In presenting every story provide a business overview of the importance and a bit of background of each story = What Business Value it has, what problem is it solving, benefits and so on.

- Focus on the acceptance criterions of the Story – avoid exhaustive repetitions of scenarios and keep it interesting and what’s valuable.

- Not Done items are not demoed.

- Never cancel a demo. If the team has nothing to demo, then display the progress at the demo- but never cancel it. Cancel the demo sets a bad signal to the team that the demo’s are not important.

- Ask for suggestions/feedback on gaining more business value.

- Decide with the PO on how to work on the feedbacks and priority.

- PBI’s are not marked as “Done” before the Sprint Review

- The DoD contains the Quality Metrics (Code Metrics), Testability Parameters(Unit Tests and Functional Tests Report) and Practices(@Prowareness we use a 30 Agile Practices list and only showcase the ones which were really DONE) used – show them, no proof only adds to the customer imagination. Transparency does wonders to build trust with stakeholders and management. Incase your customer is non technical ( have no clue about quality, educate him about him – after all he may have to spend effort/money in managing the solution later on, its his right to know what quality did he sign up for)

- Always celebrate (cheer/champagne/or just a thank you) at the end of the demo with all the team members and other involved in making the sprint a success.

Looking for the right recipe for your team demo, try the following out ?

>>Create cross functional team/group of 4-5 people

>>How would you rate(1-5) the last demo you attended ?

>>What was the best demo you ever attended and what was special about the same ?

>> Create the perfect Demo recipe (share and discuss ideas across teams)

- Audience

- Setup( Infrastructure and Environment)

- Preparation

- Execution of the Demo

- Closure