Category Archives: Agile Development

Design vs Code – The curse of Agile

Found some old notes of mine about agile, almost a decade old (note I am referring to Agile as new 🙂 ), but surprisingly the core question I was pondering upon a decade back, still holds true. The question development teams still struggle to solve is – how much time is sufficient for the design phase when one is following Agile practices.

Agile is new, bold, and sexy. Everyone wants to be Agile. Every resume I have seen of late has “Agile Development” mentioned in one form or another.

But the question is, what is Agile? Now some would say Scrum is Agile, having status meetings every day is Agile, and development in Sprints is agile. Well, if you look at the dictionary, agile is “able to move quickly and easily”. And Scrum, Sprints, TDD, etc are just some tools to get things done faster. I have shared my thoughts on agile development here.

With Agile development, I have seen too often teams trying to jump on development from day one. Design and architecture sound old-fashioned. Why spend time on something that will not show up on the screen as the end product? Why not instead spend time developing something which one can demo to clients, and get appreciated for fast work?

When you are driving, speed is attractive, but it needs better clarity, stability, balance, and most importantly synchronization if we have a team. By pushing the design to the back burner, we are saying “let’s start driving, we will figure out the route map on the way”, and before we know it, every member of the team comes up with a different route map and is sitting miles away from each other.

As would not stop people from developing unless the design is complete, but definitely some ground rules should be set beforehand.

DORA Metrics

With the popularity of the Agile development approach, frequent deployments to prod have become commonplace. DevOps teams manage these deployments, sometimes multiple deployments on the same day. With these frequent deployments, it is important to define and measure the success criteria. DevOps teams use DORA metrics to measure their performance.

Deployment Frequency: Refers to the frequency of successful software releases to production.

Lead Time for Changes: Time it takes for change that was committed to reach to production.

Mean Time to Recovery: Measures the time between an interruption due to deployment or system failure and complete recovery.

Change Failure Rate: Indicates how often a deployed changes lead to failures.

How DORA Metrics Can Measure and Improve Performance

https://www.leanix.net/en/wiki/vsm/dora-metrics

Scaling Scrum

Scrum is a wonderful framework to manage projects. It is usually talked about in terms of a single project team and how to manage product and sprint backlog for the team. But most of the times, a team will not exist in isolation. It is part of a bigger structure, and mostly the product is being developed by multiple teams who are focusing on different aspects.

Hence, it is important to understand how the Scrum framework should scale to accommodate bigger teams and projects. Here are a few techniques to scale scrum

Scrum of Scrums: This is a very basic practice to manage multiple teams following the Scrum framework. Each team sends a representative to a daily Scrum of Scrums exercise, where each representative will talk about the health of his project. This practice helps everyone to have a bigger picture, manage dependencies, call out blockers and everyone is on the same page as to when and how the next release of the product is taking shape.

Scaled Agile Framework or SAFe: SAFe is an extension of the Scrum framework for managing bigger projects. It introduces the concept of following additional teams and members

    System teams – Dev ops people shared across teams and responsible for deployments- CI and CD are created at project and product level.
    Architecture Teams- Architects that own the design for the overall system and each project team. It is important that everyone in this team understand the overall design and dependencies on other components.
    Product Managers – manages a team of product owners for different teams.
    Release Train Engineers- Scrum masters form the team of Release train engineers and manage the overall release process.

ART or Agile Release Train clubs different aspects which are dependent and can be released together.

Disciplined Agile Delivery or DAD: Disciplined Agile Delivery is the response to the teams which claim to not care about some of the core best practices in the name of Agile. If you have been part of Agile teams, you might have heard people saying that we don’t spend time on design and documentation as we are following Agile. This can cause issues especially with large projects where multiple teams are dependent on each other.

To handle the situation, an induction phase is added at the start of the project. During this phase many important things happen to help scale, like designing the solution, POCs are done, high-level architectures are created and shared across teams, release planning and roadmaps are established. After this, the normal Scrum process is followed.

Understanding the Scrum Framework

We are hearing a lot of noise about Agile project development techniques and more often Scrum-based development these days. Here I will try to answer some of the basic project management questions related to Scrum.

What is Agile?

Agile, if we look at the word only, it means fast. With the competition and fast-paced advancements in technology, it is important for software products to release features as fast as possible to the market.

With that aim in mind, the following core principles were finalized.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

What is a project charter?

A project charter is a short document which gives you an outline of the project. It normally has the following details.

Project Objectives – What is the trigger for this project.
Stakeholders- Who all are affected by and involved in this project
Constraints- Dependencies on outside factors.
Risks- Any Risks foreseen for the project and if they have been mitigated or accepted.
Definition of Done – When can the project be considered as done

What are the basic roles in Scrum?

Product Owner- manages and prioritizes the product backlog. Should have complete knowledge of the product. It helps if he also has technical knowledge.

Scrum Master – The job includes facilitating the scrum, organizing meetings, communicating with stakeholders, product owners, and team to make sure everyone is on the same page. Usually, this is not a standalone job. Normally a Project Manager will assume the role of Scrum master who might ave additional responsibility of managing resources and keeps a check on project overall health. At times a business analyst can also take a role of Scrum Master, who has an understanding of business and can take up some responsibility from product owner if the later is not available full time.

Development Team- A typical scrum development team can have following team members
Developer
Business Analysts
Tester
Technical Writer
Architect
Support or DevOps people

How the work is managed in Scrum?

Work is managed in the form of backlogs. There are a product backlog and a sprint backlog, which contains work items in the form of stories.

Product Backlog: The product backlog has all the work related to project. The product owner works with stakeholder to come up with the product backlog, which is then prioritized and mostly all the work is delivered in the form of multiple releases.

Sprint Backlog: A spring is usually a 2-3 week time period. Product owner normally prioritizes work for each sprint, which is then added in form of Sprint backlog.

What is the Scrum process?

The product owner creates product backlog with the help of stakeholders. This usually has all the work which has to be taken up during the course of the project. Work is done and delivered in the form of Sprints. A sprint is usually a 2-3 week time period, in which a small but complete chunk of work is picked up by the team and completed.

The process starts with spring planning where tasks to be delivered for the current sprint are finalized. Daily scrum meetings are conducted where ever team member provides the status of work done. At the end of Scrum, a review and a retrospective meeting take place to showcase the progress and evaluate process improvements respectively.

What is Sprint Planning?

In the sprint planning meeting, the Product backlog is reviewed by the team. The product owner prioritizes the stories to be taken up for the sprint. Team reviews, discusses and refines the stories. Finally, Team commits to a set of stories, which then is treated as sprint backlog.

One should Avoid long discussion on requirements and design in planning meetings. If things are not clear, the story should be dropped and re-reviewed by the product owner or architects / senior devs separately. Ideally, there should be a pre-planning meeting among senior devs, product owners and scrum master to save the time of the team.

Pick stories which make logical sense in delivering an incremental update.

What is Planning Poker?

During the sprint planning meeting, the complexity of all the stories being considered for the sprint is decided. Based on which the final sprint backlog is decided, considering how many stories can be taken up during the sprint. Knowledge from previous sprints is used to understand how much complexity can be handled during the sprint.

Planning poker is a process to involve all team members in evaluating the complexity of a story. A base story with a base complexity, called story point is used for comparison. Every team member gives complexity or story point (normally in Fibonacci series) to each story. Outliers are discussed and the team comes on a consensus for story points.

It helps everyone understand the story and make sure everyone is one same page. Every voice is understand.

What is Daily Scrum?
A daily standup meeting where each team member talks about the following three items

    What was done yesterday?
    What will be done today?
    Any blockers

Advantage of daily scrum meeting is that everyone knows what is happening through the project, and team members can help each other or call out dependencies on other’s work.

Usually, a Kanban board or Scrumban board is used to track stories and tasks. This helps in making sure that only a fixed set of stories will be taken up at a point. There can be 3 or more states for a story or a task i.e. New->In Progress-> Done.

What is the Sprint Review?

At the end of a sprint, the team showcases the progress to the Product Owner and other stakeholders. The progress is shown in the form of a working product or demos. One should make sure that there is representation from all stakeholder parties so that everyone agrees to the product being built.

What is the Sprint Retrospective meeting?

This meeting is among team members at the end of a sprint where everyone is supposed to discuss on following items for the last sprint.
What went well?
What can be improved?
How can we improve it?
A plan is created for improvements and tracked.

What goes into a sprint?
Sprint Backlog

What is the outcome of a sprint?
A Potentially shippable iteration of the product. That means designed, developed, tested, unit tested, integrated, acceptance tested piece of code.

What is a user story?

A user story is usually the smallest yet complete work item which can be delivered in entirety. The story can be further divided into tasks. A story has the following components – Value statement, Assumptions and Acceptance Criteria.

A value statement is normally stated in the form of
As a [Who]
I want to [What]
In order to [Why]
For example, “As an Admin, I want to access the settings page, in order to update language option.

Assumptions are any additional information about the story implementation as if it is dependent on another story or other stories are dependent on this, how these will affect each other.
For example, “Assuming external service is ready or takes {set of input} params.”

Acceptance Criteria is testing criteria of the story. This also covers any nonfunctional requirements like performance or security needs. Acceptance Criteria removes ambiguity and provides the sort of a checklist for completion of the story.

In addition, a story will also be associated with Definition of Done, which is defined at the product level. This can include –
Reviews by stakeholders
Documentation
Design and compliance reviews

Tripple cost constraint

The age-old knowledge we have that when building a product, you can choose two of the three – Cheap, Good and Fast.

So if you need something to built with good quality and fast speed, it won’t come cheap.

In terms of a software project, these constraints take the form of –

Scope
Budget
Schedule

Quite often, a project manager is caught in the dilemma of controlling these aspects of the project. Striking a good balance among three is often difficult.

Let’s take a look at some of the practices we can use to manage these three aspects.


Scope

In a traditional project management approach, you would use Work breakdown structure (WBS), to define feature components which we need to develop. If a change comes in at a later point of time, that has to go through a Change Control Board (CCB), which will analyze the impact and approve if required.

In a lean project management approach, the scope is controlled in the form of tickets and requests.

In the more popular agile project management approach, we control scope in terms of the product backlog and sprint backlog.


Schedule

To manage the schedule in a traditional waterfall approach, techniques like Program Evaluation and Review Technique (PERT) and Critical Path Method (CPM) are used

In the Lean project management approach, Kanban & Queues are used to manage the work. The work is managed in a list and executed based on priority. Service Agreements sets the priority of work by defining what is critical, major, or minor.

In an Agile project management approach, a Sprint based model is popular to manage scope, where releases and roadmaps are used to set goals for major features to be released together.


Budget

In the traditional project management approach, we use Earned Value Management (EVM) approach which compares current performance Earned Value (EV) to the Planned Value (PV) and evaluate it over Actual Cost (AC) which is the cost so far to complete the work

In the Lean project management approach, we control KPIs or Key performance indicators to showcase the outcome of the work done.

In Agile project management, we measure Return on Investment or ROI, and Burndown charts to measure performance.

Design before you code

Somehow, with the penetration of agile development practices, I have been observing that less and less time is spent on designing the solution. Engineers treat Agile as a license to develop without design.

What is the problem with developing without designing or architecting the system first? I still remember when I was in college, my professor drew a parallel between architecting a building and architecting a software. Would you start building a house without thinking about design? you will not just start placing bricks without considering how many rooms you need? Where all these rooms go? How large should be every room? Where will the kitchen and bathroom be? Where all the wiring and plumbing will go? You will come up with the design, put in on a paper or a software and then calculate the feasibility.

Think of the complications that can happen if you build your house without thinking about design first. One room might be so big that there is very little space for the others. Or you are not left with any space to create a bathroom. These mistakes are costly. And that brings me to the other important factor which is causes ignoring of design in software. The manager thinks that change at a later state is going to be easy. At the end it is code, we can just change it. Well, changing the code is definitely possible, but never easy or cheap. It comes with its own cost.

More than often, where developers need to make changes at a later stage, they would be more inclined to apply quick fixes or hacks rather than making a bigger correct change. Of course, you have a tried and tested code in hand, why would you make too many changes to it, even if you know that is the right thing. And then there is developer ego, I mean, let’s admit it, it is not easy to accept one’s fault, especially if that means you would need to put in extra hours to fix that. More than ego, it is actually denial at times. People would try to stick to the solution they developed initially even though it is realized at a later stage that there could have been a better solution. Reason being, you have already invested too much.

This situation can be avoided if we think about design first. We can make sure our design covers all the possible requirements. It will not be possible to anticipate all the changes that are going to come at a later stage, but we can try to keep our design flexible. The idea is, set the ground rules, understand what all component and services we are required to create? What all data needs to be persisted and how are we going to do that? How security and error handling will be done? We need not get into implementation details, but the high-level design is a good start. We can fill in the details as and when requirements are clearer and we start actual work on the given piece of requirement.

In the end, all I would like to highlight is, if you think you are saving time by not thinking about the design of the application before you start to code, you are going to end up spending more time applying patches and fixes at the end.

Krutchen 4+1 Architectural view model- Agile perspective

I have a strong belief that Solutions Architecture is as much of a science as it is an art. There is no set of fixed rules you can apply to get a final architecture. There are rules, but they can get changed based on kind of project, teams and constraints you are working with.

Coming to 4+1 Architectural view of software architecture, Krutchen shared an interesting way of looking at software architecture in this paper.

Original paper- https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

In crux, the paper suggest that we can look at any software architecture from 4 perspectives or views to get a complete picture.

Logical view: This is end user view of the system. How many entities or classes are there and how they interact, for example, how Employee will be related to Department and Project, what will happen when someone joins or leaves an organization.
UML: Class Diagrams, State Diagrams.

Process View: This talks about how the business works as a process. If you need to open an account in a bank, what process needs to be followed. In addition, we take care of non-functional requirements like scalability, performance etc in this view.
UML: Activity Diagrams

Development View: This is a view for developers, understanding how the system will be implemented (also known as implementation view). How many components will be created and how will they interact with each other.
UML: Component Diagram, Package Diagram

Physical View:
This view explains how this system will be deployed physically. What kind of machines are there and how these are interacting.
UML: Deployment diagram

Scenarios: Scenarios or Use cases are given special attention. Because before getting into any other views, one needs to understand all the use cases we need to handle for the system being developed.

Well the paper explains about these views in details, so here I would like to add my understanding of how to use this model in agile development methodology.

Agile Perspective:
When you are building a software in agile manner, you are taking up one use case at a time, broken down in form of stories. Once you have sorted out what all use cases are you dealing with in current sprint or cycle, you can start by understanding logical view for these cases. Moving on to Process view then Development view and finally Physical view, case by case. So rather than creating the whole picture in one go, we will be creating our architecture as and when we are working on a particular use case.

Understanding Agile

I have heard many versions of people defining Agile development. I met someone who claimed that they use Agile development in their project. When asked how can they say they are doing Agile development, it was told that team meets in the morning everyday to discuss status and hence the project is using Agile development.

I have also heard people talking about Agile development in a manner that it will automatically solve all your development problem, they do not realize if not implemented properly, Agile development methodologies can actually backfire. Others confuse Scrum with Agile development, well they are not completely wrong, but one needs to realize Scrum is a Agile Framework like Kanban, Extreme Programming, SAFe etc.

Keeping it simple, lets take a quick look at Agile manifesto.
http://agilemanifesto.org/

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And then 12 principles
http://agilemanifesto.org/principles.html

We are talking about focus on customer satisfaction, continuous delivery, accommodate changing requirements, frequent collaboration between Business and development teams, focus on people than on processes, more focus on face to face and frequent interactions, focus on working software, reflect on current processes frequently and self improvements.

One thing to note is Agile development methodologies or manifesto nowhere gives a series of steps or rules. These are guidelines, which one need to apply to ones project. This will definitely help but there is no silver bullet. There are Agile frameworks and methodologies as mentioned above, but you still need to figure out what will work for you rather than blindly following some document or advice of a so called expert. Best way is to look at as many methodologies and frameworks as possible, pick up the practices which you feel will work for you, and keep on validation after a short period what is working and what does not.

Agile Mobile Development

One of the best candidates for agile development I have found is mobile app development. Why?

1. Requirements are usually not very clear as mobile app development itself is relatively new- so client demos and regular feedback helps us not to move away from what is required.

2. The mobile technologies have not been explored as much as we have already explored web technologies, so we still have lot of challenges to be faced. This means peer reviews and pair programming can be very helpful.

3. The apps are generally UI extensive, that means they are good candidates for client feedback. We need to get clarity on look and feel, and specially responsiveness of the app.

4. With frameworks like phonegap available and newly emerging augmented reality libraries, complex mobile apps are normally started in POC (proof of concept) mode. With hit and try approaches, it is good to have daily discussions to float ideas and get feedbacks within the teams.

Refer : http://kamalmeet.com/2013/06/agile-development-what-is-it/
http://kamalmeet.com/2013/06/agile-development-is-it-for-me/

 

Agile Development- Is it for me?

Agile practices are becoming popular day by day. In my last post I took up the question Agile Development- What is it? But the important question for a development team or manager should be Agile development- Is it for me? Is it the right choice? Should I use it just because it is working for someone else?

Every coin has 2 sides and so does agile methodology. If there are benefits of using it, it can also hurt the development process if not used intelligently. For example, if a project does not have many UI elements and has more complexity at backend like handling of MDBs and Web Services, having a client demo every week will not be very useful as we will not have anything new to demonstrate. Similarly, if the requirements are mundane and team has already worked on similar requirements already, pair programming will cause a negative impact on productivity.

While going for the agile approach, we will need to analyze if it will work for project in hand, rather than trusting it blindly. Ideally we should be checking each agile practice in detail and see if this is something I can use, and not go for the complete package.

For Example:

Continuous Client Feedback: If my requirements are not very clear, or are prone to changes or software has heavy UI element which needs to be verified by client, I should definitely plan weekly or biweekly demos based on project complexity and requirement.

Test Driven Development: Need to analyze how much automated test scripts will be required. Black box and white box test cases needs to be analyzed. Test cases can be created in parallel of code rather than before coding starts. If requirements are prone to change it might not be useful for me to create automated test scripts beforehand.

Face to Face Communication: if we are working in a model where teams are scattered across globe, we will not be able to follow this. Conference calls might be helpful.

Pair programming: In case we are working on a cutting edge technology which is new to team and having more than one mind concentrate on a problem will help, this is definitely the way to go.

Similarly we will need to take a call on what will work for my project rather than following the herd and going agile mindlessly.