Lean Mastery Collection
Page 18
Step 1: Define a vision
What is it?
At the start of an Agile project, it is required that a clear vision of the project is defined. This means the project manager and the team sit down to determine the reference ground of the project. For a product company, the way to know the vision of a project is to use an Elevator Pitch. However, companies that are building something different other than a product, they need to modify the Pitch and make strategies that suit the needs of the company.
Who should be present?
In this stage, one has to find out the prospective clients of the product. It is advised to invite major stakeholders such as managers, product owners, and company directors.
When should it happen?
It is important for the strategy meeting to take place before the start of any project to help keep the mission of the project alive.
How long should it last?
While this depends on you, a good strategy meeting should last between 4-16 hours, but it should have some breaks in between.
Step 2: Create a roadmap for your product
What is it?
Once the strategy is approved, the product owner should transform that strategy into a product roadmap. This is a complicated view of the project requirements that have a loose timeframe for when to create each project.
The ‘loose’ timeframe is very critical here because you can’t spend a whole month planning for each step. Therefore, one should aim to prioritize, identify, and create a rough estimate of each product piece. This will facilitate the delivery of a product that is ready to be used.
Things that should be present
It is the role of the product owner to create the product roadmap, but it should also have some buy-in and contribution from other stakeholders who take part in the project.
When should it take place?
Make sure that a roadmap exists before planning for the sprints. Therefore, it is better to begin building a product once the strategy meeting is over.
How long should that last?
Agile Project Management requires rapid development of a product. There should be no delay in the early stages of planning. However, the product roadmap is the mission of the product, and it has to last until that time when the product owner can feel that everything has been covered.
Step 3: Get ready with a released plan
What is it?
So far, there is already a strategy in place and a plan that defines the time. At this point, it is the role of the product owner to create an advanced schedule that will define the subsequent dates of release of the working software. Keep in mind that Agile projects have numerous product release before the final product was released. Therefore, a product owner has the option to place emphasis on the product features he or she wants to launch first.
For example, if a project started on November, one can schedule to release it on February before again releasing it in May when the most advanced features have been developed. However, this depends on the level of complexity of the project and the length of the sprints.
Who should be present?
The top members of the organization should be present on the day of product release. Team members and managers should be present, as well. A few stakeholders will also help get the team fired up.
When should it happen?
It is good to ensure that the release of a working product takes place on the scheduled date.
How long should that take?
Be realistic about the length of a session. Pay attention that it does not slow things down. An interval of 4-8 hours should be appropriate.
Step 4: Plan your sprints
What is it?
This should be the time to change from a macro view to the micro view. Make sure that the sprints are short with specific things to accomplish. You can set the sprint to last for 1-4 weeks and maintain the same length for the whole project since this will help teams to plan in an accurate manner.
When starting a sprint cycle, make sure that a team builds a list which includes a backlog of items to complete in a given timeframe. This will help one to release functional software.
Who needs to be present?
This is a collective responsibility of the whole team. In other words, the project manager, the owner of the product, and the team members should be present to speak out their suggestions about the product.
When should it take place?
Planning for a sprint always takes place at the start of every sprint cycle.
How long should it last?
Remember that by planning for a sprint, it sets the tone for the cycle, although, you don’t want to take a lot of time at this stage. It should last for 2-4 hours. Also, once the sprints are planned, the team can start.
Step 5: Ensure your team is on track
In the entire process of creating sprints, there must be time to deal with all the challenges that come on the way. A lot of these challenges are those that can slow down the time to achieve the goals. Therefore, a project manager should organize for daily meetings with their team. The meetings can last for 15 minutes.
Some of the things to discuss in the meeting include:
• What did the team complete on the previous day?
• Current tasks that the team is working on.
• Challenges that the team has experienced.
Although this may sound like a waste of time to some of the members of the team, holding such kinds of meeting help clarify certain things in the meeting. Remember that Agile practices call for a quick response to problems, and raising these problems in public is the best way to develop team collaboration.
Step 6: You have done sprints. Time to review
What is it?
Let’s assume that everything has gone well according to plan. Therefore, before the end of each sprint cycle, the working software should be ready to be presented. This is the right time for the team to go through everything before presenting it to the stakeholders and other guests present.
The best approach to take is to review the initial plan and confirm that all the requirements have been met. As the product owner, the decision is yours to decide whether certain functions should be removed or not. In case you are not satisfied with a given functionality, it is your right to question. Find out how they can adjust their speed of working so that they can meet the targets of the next round.
Who should be present?
The whole project team plus stakeholders must be present during each sprint review. Each group of a participant must suggest their feedback after seeing the product.
When should it happen?
The review of a sprint should occur at the end of each sprint. This should not last more than an hour or two.
Step 7: What is next? Choose what you want to focus on in your next sprint.
What is it?
For Agile Project Management to work correctly, there must be a template or rough draft available to show what should be done next. This should be defined in the next sprint. Once a sprint is complete, that is the right time to outline activities and tasks for the next round. To help determine what should be done in the next sprint, it is important to revise the recommendations of the previous sprint and figure out how to integrate that to the next one.
Who should be present?
Stakeholders, directors, and team members of the project should be present.
When should this happen?
It is good when a sprint retrospective can take place after a sprint review.
How long should that happen?
Make it short and interesting. One to two hours is enough to review the current sprint and briefly plan the next.
What should happen then?
At this stage, it is important to have working software to ship for users to review and send feedback. This is the right time to plan for some new features. An important feature that makes Agile the best practice to use is the endless shipping, building, and learn
ing.
Agile supports the release of a half-baked product and letting users send feedback about the product. This means that one is able to recognize a missing functionality early before the final release of a product.
Chapter 3: Agile versus Waterfall Model
In this modern era, smart project management has risen to be an important tool for businesses. Smart project management is the reason why businesses are running smoothly without experiencing challenges in their processes. So far, every business, whether small or large, is making use of technology and better project management tools to ensure that it builds the right software and deliver the correct software. Regardless of whether it is team collaboration, the use of these tools has enhanced the software development process. In fact, it has made everything run so well with the least challenges.
Although there are numerous approaches to apply when it comes to managing a project, the most outstanding approach is the Agile Project Management, since it is flexible and practical. Agile practices provide one with multiple abilities to perform several tasks. This is one of the reasons why it is very popular. Below are some of the differences between Agile and the traditional approach.
Traditional
Agile
Overview of Agile versus Traditional Project Management
Define Traditional Project Management
A lot has been discussed about Agile Project Management and how good it is for project managers to use in their software creation process. However, to understand correctly how good it is, one must first understand how the traditional project management works.
The traditional approach is also called the Waterfall Model. This name was founded based on its shape. This approach assumes a linear pattern where each stage of the process occurs as a sequence. The basic idea of the Waterfall model is predictability. Predictability refers to the forecasting of experience and tools used. Each project assumes the same life cycle. The stages involved include planning, designing, testing, feasibility, and production support.
With the waterfall approach, planning takes place early without a scope to alter the project requirements. This approach focuses most on the time and cost but the project requirements remain the same. This is one of the reasons why projects created using the waterfall model have budget and timeline challenges. The table below shows a summary of the differences between Agile and traditional project management.
Features
Traditional
Agile
Project Scale
Large-scale
Small and medium scale
User requirements
Defined clearly before any implementation
Interactive form of input
Organizational structure
Linear
Iterative
Client Participation
Low
High
Development process
Life cycle model
An evolutionary delivery process
The cost of restarting
High
Low
Model of development
Fixed
Dynamic
Testing
Done after coding
Each iteration
Requirements
Standard and known at the start
Emerges with rapid changes
Architecture
Generates current and predictable requirements.
Generates current requirements
Why do we prefer Agile and not the Waterfall Approach?
Agile is preferred by a lot of developers and project managers. Let’s find out some of those reasons:
• Project complexity
Agile
This is the right methodology if an organization wants to find a solution to a complex project. An advanced project might contain different phases that are joined together and each stage might depend on other stages instead of just a single one. This is the reason why most project managers prefer to use Agile for large and advanced projects.
Traditional
For small projects that do not have complex features, the traditional approach could be used best. However, one must still recognize that there may be unexpected changes in the project or certain complexities which can affect the whole process and force one to go back to step one.
• Adaptability
Agile
Agile is popular because of the level of adaptability it brings in the project development. Complicated projects have multiple stages that depend on each other. Since Agile methodology provides for adaptability, one can take a risk and change something in a given stage.
Traditional
In the Waterfall approach, the concept is that once a specific phase is done, there is no going back. In short, there is no adaptability in the traditional approach. In case a client requests for sudden changes to be made, it becomes difficult to change. The only option is to navigate back to the first step. This can really waste a lot of time.
• Scope to receive feedback changes
Agile
When it comes to getting feedback about a given software product, Agile Methodology is the best in this sector. This is because it has a flexible process that embraces feedback once a product is released to users. Feedback helps improve a product as well as fix any issues. Flexibility in the Agile methodology is the major reason why most organizational managers choose to use it. Software developers who code using this methodology can respond fast to customer requests because they deal with small tasks in the big project.
Traditional
In the Waterfall model, each step is defined in detail before one can begin implementation. This approach cannot deal with sudden changes or feedback that might require quick responses. In most cases, the traditional approach has both a fixed time and budget.
Features of the Agile project development
Breaks project into smaller parts
Agile works by dividing a project into smaller chunks called iterations. Then, the iteration is sent to the customer for review. The success of an Agile project depends on what has been achieved after every iteration.
Self-organized
In Agile development, there is a parallel management model. This is where company employees aren’t just managed by a single individual but by a group. Generally, Agile projects have three parts:
• The owner of the product
• The scrum master
• The team
Customer participation
When it comes to Agile development, the customer is the first priority. The customer is very important in the built-up of each of the iteration. The role of the customer is to review the iteration and provide feedback. Once the feedback is out, the right action is taken.
Overall, Agile is the leader in the project management system. When you compare it with other approaches, Agile’s features are at the forefront. That is why, it is the leading software project management methodology.
Chapter 4: Learning more about Scrum and Agile Principle
Scrum and Agile are terms common in the field of engineering. They are phrases mentioned by tech engineers. It is like part of their language. However, this language can be frustrating to a person who is not used to it.
Scrum and Agile: What is it?
Things may not be easy when you think of starting with Scrum and Agile. The two words can confuse anybody because one can end up using them interchangeably. However, don’t get confused because both words have a different meaning.
So far you know the meaning of Agile. No need to define it here. What about scrum?
In summary, Scrum is a framework used in Agile development. An example to illustrate the difference between Scrum and Agile is the difference between a diet and recipe.
An individual who eats vegetables has a diet prepared based on certain methods and principles. A recipe for cooking vegetables is the framework used to create a diet for a vegetarian. This analogy tries to explain how Agile and Scrum
are related.
Who can benefit from using Scrum?
It is wrong for one to think that Scrum was built only for engineers and developers. In fact, this framework can be used to build any other project. One can use Scrum in any type of project whether it is in the market industry or any other type of industry. Scrum is the right framework to use to gather ideas and organize a project team.