Register

  • The password should be at least twelve characters long. To make it stronger, use upper and lower case letters, numbers, and symbols like ! " ? $ % ^ & )

Category: Scrum

Why Going Agile And Embracing Change Is Easier That You Thought

Introduction

Why Going Agile And Embracing Change Is Easier That You Thought

Inside every project manager is an ‘agilist’, trying to get out. In fact, that’s true of everyone in a project team. While the status quo and comfort zones have an undeniable attraction for our lazy streaks, we’re not made to do the same things over and over again. We may be apprehensive about change, but we also need it. The perils of endless repetition include boredom and rapidly increasing error rates. So what’s the answer?

A little root cause analysis will help here. Change is stressful when it involves the unknown. We worry about whether we’ll feel good about what comes after, compared to what we had before. When constant change is a fundamental part of an agile project approach, it can turn into a real tug of war between the urge for variety and the fear of failure or degradation of a situation. The pressures of project sponsors and end-customers for delivery of new products or services then exacerbate the problem.

But good methods for managing change and succeeding with agile methodologies can be learned. Agile project management may be characterized by fast-moving activities focused on action for rapid results. Yet it still relies on well-defined concepts and techniques to work successfully. It can be taught, internalized and then applied with confidence – and therefore without stress or worry – about the quality of the output of each agile cycle. Going agile and embracing change can then become a source of satisfaction for all concerned.

Quick Tips For Scrum Meetings That Work

Introduction

Quick Tips For Scrum Meetings That Work

 

Make no doubt about it the early scrum (Planning and Daily)  meetings set the tone for all the following activities of the project. With Scrum, life cycles are short and the pace hot with little time afterwards to re-jig team attitudes and behavior.  With the early meeting setting the tone for the rest of the cycles I suggest that you create an additional scrum kick-off meeting.  This can help to ensure that subsequent scrum meeting are focused on the scrum job and not the “ground rules”

This Scrum kick-off meetings gets the getting to know how it works out of the way. Subsequent team meetings will need to be rapid stand-up ‘huddles’ lasting for all of 15 minutes, you don’t want your kick-off meeting to seem too leisurely. Yet you also want to take enough time to set the scene properly for future success. The following tips may help:

  1. Remember that Scrum is also about trusting people’s ability to solve problems. The team may be the best source of answers for some questions that arise.
  2. Make sure your whole project team is there, for full input and engagement. Change the date to accommodate anyone who has a schedule conflict.
  3. Notwithstanding quick-fire project meetings in the future, allow plenty of time for the kick-off meeting.
  4. Make sure team members get to know each other. Fun exercises and games are one possibility.
  5. State or remind the team of how Scrum works and the roles of the Scrum Master and project team members.
  6. Agree on definitions (when is a deliverable truly ‘done’) and project tools (specific project management and issue tracking software, for instance).

When you get steam up on your Scrum process afterwards, remember that from time to time, it’s good to have periodic get-togethers along similar lines to the kick-off meeting. This can be an important factor in maintaining team enthusiasm, cohesion and momentum.

 

User Stories – Invest

Introduction

The Six Attributes of a User Story and Why They All Count

The current best practice in Agile Software Development to clearly and briefly describe the functionality from the end-user’s perspective is the User Story. High quality User Stories will become part of the product backlog iteration. Weak User Stories are a waste of time and should be avoided at all cost.

This article will teach you the six attributes every effective user story must possess to pass the backlog quality check and ensure you spend your time right.

The INVEST Mnemonic To Writing High Quality User Stories

This simple, yet profoundly powerful mnemonic is a creation of Bill Wake the co-inventor of Extreme Programming.
I = Independent
A great User Story has the potential to stand for itself. By following this criterion the story can be scheduled and implemented in any desired order. This makes the story usable in different contexts and for multiple concepts.

N = Negotiable… and Negotiated
Outstanding User Stories are co-created by the programmer and the user. Only the main essence is captured, while the details are steadily added and influence the whole backlog in an iterative manner.
V = Valuable
All great stories add specific value to their target audience, in this case: the user. Especially when splitting stories, each individual piece should address one very specific area in which value is created, while telling the overall conceptual story.
E = Estimable
Every User Story must be estimable in order to be considered for a ranking by the customer. The degree of ratability is directly linked to the story being negotiable. Only stories that are understood by all stakeholders are estimable in scope and budget.
S = Small
A Story should not be overwritten and only focus on one key value adding idea. Keeping it within the range of a few person-days and at most a few person-weeks ensures that the story will be estimable.
T = Testable
Stories must be testable in order to be considered for the product backlog. If a story is not testable due to a lack of information it probably is not estimable and does not provide specific value to the customer.
All of the six attributes have to be considered in order for the User Story to be implementable. They affect each other in an iterative manner. Shortcomings in one area may lead to an information deficit in another and towards an unusable story.

Take the time to check your User Stories for all of these attributes. Time has shown that a Feedback Circle of Proposing – Estimating – Implementing is the most effective way to produce a great User Story, implementable in many different contexts.

Where to with the user story when completed
A user story is typically functionality that will be visible to users, by users this includes end users, administrator’s manager. To create a user story will require a number of tasks to be completed. These tasks are often shared out among a range of people such as analysis’s, designers, programmers and testers so each has their own task. When put together the tasks complete the user story.

User stories appear on the Product Backlog and tasks appear on the sprint backlog.

Include INVEST workshops as part of good Scrum Master training and coaching.

Agile – Back to Basis

Introduction

Back to Basics: When was the last time you looked at the Agile Manifesto?

The Agile Software Development method was officially introduced in 2001 (http://agilemanifesto.org/). However, evidence of similar incremental software development methods dates back to as early as 1957. The recent hype due to the method’s continuous improvement and rapid development led to confusion and information clutter.

It is time to take it back to the basics today and focus on Agile’s core values.

Honestly, when was the last time you looked at the Agile Manifesto? If this has been a while ago, here is a quick summary to refresh your memory and help you focus on the core conceptual framework.

The Agile Manifesto – The Key to Success in Agile Development

The manifesto was laid out in February 2001, when 17 software developers met in Utah to discuss lightweight development methods. The results have been groundbreaking. Here are the main values and working principles.

The 4 Core Values of Agile
In order to uncover more user-friendly ways of software development, the following values have been announced.

Individuals and Interactions>Process and Tools
Working Software>Comprehensive Documentation
Customer Collaboration> Contract Negotiation
Responding to Change>Following a Plan

Are you following these core values in your recent Agile project? If not, do not be surprised if the project lacks in success.

The 12 Core Principles of Agile

1: Customer Satisfaction: Develop valuable and useful software quick

2: Welcome Change: Make changes during all stages of development

3: Frequent Delivery: Produce little working chunks of software constantly

4: Close Cooperation: Co-create the software with all stakeholders

5: Motivate Individuals: Develop a working atmosphere of mutual trust

6: Direct Communication: Talk to involved parties face-to-face as much as possible

7: Working Software: Produce software that creates results

8: Sustainable Development: Maintain a constant development pace

9: Continuous Attention: Focus on technical excellence and good design

10: Simplicity: Maximize the amount of work not done

11: Self-Organization: Allow teams to self-organize around their strengths

12: Regular Adaptation: Adapt to changing circumstances

 

These principles can be applied to almost all processes of your business. In Agile, they are crucial towards the efficient and timely achievement of real results.
These core values and Principles are vital to the implementation of an agile process, it is essential that you regularly look to these principle to ensure you are not just following a process but truly building an agile environment.

Scrum Master Is Not A Project Manager

Introduction

Scrum Master Is Not A Project Manager

The Specific Reasons Why a Scrum Master is Not a Project Manager

Companies new to Agile often fall into the crucial trap of mistaking the Scrum Master role with the role of a Project Manager. This often leads towards a dramatic detriment in productivity, since the Scrum Master role requires a very specific skillset which is entirely different from the more generalist role of a Project Manager.
This article will point out the main differences between those roles and help you to chose the right person for both positions to make your project a success.

The Classical Role of Project Management
The Project Manager leads the project on a day-to-day basis, controls, communicates and provides direction. His role can be summarizes into the four following categories:

1: Manage Processes: The Project Manager gets the project “up and running”, selects the team, establishes milestones and project schedules with the team and leads the project on a daily basis

2: Track Process: The Project Manager monitors the timely achievement of milestones, tracks team costs and investments, overseas the documentation and provides direction

3: Facilitate Cross-Functional Collaboration: The Project Manager Identifies linkages between sub-projects and coordinates cross-team cooperation

4: Communication: The coordination of key project-related messaging to internal and external audiences, as well as communicating project information to the line management are Project Management roles

 

The Specific Role of the Scrum Master

The Scrum Master on the other hand does not manage the team on a daily basis. His role is more of a coaching and a facilitation role regarding Scrum, which makes him the link between the project team and the client.

Scrum Masters cooperate closely with the Executive Sponsor. They ensure that the project complies with Scrum and that all processes are implemented properly. The role can be summarized into the 3 following categories:

1: Overcome Stumbling Blocks: The Scrum Master steers the development, resolves problems and involves the right people in the development process

2: Oversee the Groundwork: The Scrum Master keeps two eyes on user experience, functionality issues and feedback from all stakeholders

3: Provide Guidance: Helping to facilitate changes and assist in the planning process while providing overall Scrum guidance is a crucial function of the Scrum Master

There you have the main difference:
The Scrum Master is there to help and assist with highly specific technical knowledge but not to manage the workflow.

 

Summary: The Scrum Master is not a Project Manager
The role of the Scrum Master is more specific and technical than the more general role of a Project Manager. Both are important. Confusing these roles however almost certainly leads towards failure in the execution of Agile – and towards huge losses.
Make sure you have these important positions covered with the right people.

scrum-training-638x321

Is Estimating A Waste Of Time

Introduction

Is Estimating A Waste Of Time

Our world is built up of plans and estimate, business judge the CEO’s and senior manager by the estimates they produce and how they deliver on them. Without estimate we can’t prepare for the future.  In our daily life we plan using estimates, like how long will it take us to get to the airport, how much will we need to put aside for our summer holidays (vacations?)

The process of doing estimates has significant influences on our decisions making. For example can we afford our trip to France, or how long do we leave for the airport before the flight. Failure to make accurate estimates could have a lasting impact. We could miss the flight, or we could overspend on the holiday resulting credit problems.

Clearly for big business and for smaller personal decision estimation is vital. It is no less vital for our development or business change project to have a handle on the costs and delivery timescales. But is estimation the way to do.Business stakeholder need to incorporate the estimates into their cost and deliverables. They need to be bought into the estimate in order to buy into the project. When an estimate is asked for, it’s critical to understand why an estimate is needed.

In scrum we estimate in detail, scrutinise, reviewed and update these estimates regularity. But the purpose and timings of these estimates is not what the business stakeholders is looking for.
Business stakeholders want to have some idea of when they’ll get which features, the number of resources needed to meet a timeline, and of course costs. None of this information can be provided without taking time to do some estimation and planning.

To get to a satisfactory solution to the conflicting requirements we need to separate out the stakeholders requirements into the 3 elements and deal with them separately.

1. Planning
Planning gives the business an idea of the resources timescales and activities. The act of planning is a large part of the value, not the piece of paper the plan is written on. This plan is not about specific component delivery but about how we deliver the cycles and more importantly it is to come to a shared understanding of what we as a team can achieve.

2. Budget
Budgeting projects uses a top down approach, where you decompose only so far as you need to in order to have enough information to make your decision.
Budgeting can be done in much less time and Budgets make better sense “what can you do for €XX.xx” This approach clears the way for the product owner to set some of the priorities.
Secondly Knowing the customer’s or management budget expectation impacted the developers’ estimates. It’s called anchoring.

3. Agile Estimates
It is easier to have confidence that we can accomplish small things than big things regardless of what number we attach to that smallness/bigness. Agile estimates are small, lower level and feed into the budget and cycles that we have set out.
We are close to the action and have more confidence that we can deliver the controlled delivery. Smaller results in less variations and the variation in estimates easily to manage. The delivery teams can then stand over their estimates.

Agilists must accept the need for revenue and budget forecasts to be taken seriously

It is easy to join the chorus of opinion that software project estimation is waste and must be eliminated. Whilst I can understand the objections to spending valuable time preparing and rationalizing a set of estimates for ill-defined features or projects.
Breaking it into the 3 process can satisfy bot the business and the agilest.

Agile Development: Making Sprint Retrospective Meetings More Productive

Introduction

Agile Development: Making Sprint Retrospective Meetings More Productive

Sprint Retrospective is the opportunity for the entire Agile Team (Product Owner, Scrum Master and Development Team) to inspect and create an action plan for improvements to the next sprint. The meeting helps the entire team to identify what worked well, and what should be improved.

I have some tips for making sure the meetings go swimmingly:

  1. The Scrum Master must be well prepared as a facilitator for the meeting.

There are thousands of retrospective techniques published in books and blogs, which when applied well achieve wonderful results. The main question is how and when to apply one particular technique or flow rather than another. However, an important issue is not only knowing the technique but knowing how to facilitate a retrospective.

Expertise in conducting good retrospectives is only gained after a period of experience. There is no single way for the Scrum Master to conduct good retrospective meetings.

The points below will help the Scrum Master to be prepared for the meeting:

  • Be prepared: Collecting relevant facts prior to the sprint cuts out the discussion as to whether, say, we have 20 or 25 stories completed.
  • Let all participants express their points of view.
  • The more the Scrum Master knows the team and the people, the more efficiently he or she can conduct the meeting. Get to know you team mates, and help them express themselves.

2. Choose a good time for the meeting.
The scheduled day and time of a Sprint Retrospective is very important, because depending on the team and the daily work scenario, people may be tired, or focused on other important aspects such as deployment or bug fixes. You have to make sure everyone is available. First thing on the day after the sprint finishes sound good, but team members may also need time to gather their thoughts.

3. The product owner needs to be present.
It is critical that the product owner is present to make a meeting effective and more productive. This is even written in the Scrum Guide. The first sentence of the Scrum Guide on Sprint Retrospective is as follows: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create an improvement plan to be implemented in the next Sprint.”

Since the Scrum Team is composed of the three Scrum roles, including the product owner him/herself. The presence of the product owner is mandatory, whether or not your Scrum Team enjoys it.

4. Do not look for the guilty.
One of the biggest fears when people enter a Sprint Retrospective is that the meeting becomes a witch hunt, where the only thing that matters is to find whoever is guilty for the problems. To avoid this, it is very important that the team understand the objectiveness of the meeting. The team should be prepared from the outset to listen to constructive criticisms so that they can create an action plan of improvements for the next sprints.

This will only be achieved after a time of maturation of the team within the Agile methodology, so these discussions should be encouraged by the Scrum Master.

PMP – Applying for and Scheduling the Exam

During the software development process it is vital to establish a robust process of software quality assurance, even if you are developing using an Agile development methodology.

Planning & Execution of Test Cases during Agile Development Iterations

During the software development process it is vital to establish a robust process of software quality assurance, even if you are developing using an Agile development methodology.

Business Analyst is not the same as a Product Owner

The key is in the name, its all about ownership. A Business Analyst collects and analyses requirements which is a major part of a product owner role but there is a lot more to it than analysis.

#iguru_soc_icon_wrap_5f733bc759890 a{ background: transparent; }#iguru_soc_icon_wrap_5f733bc759890 a:hover{ background: transparent; border-color: #116cb6; }#iguru_soc_icon_wrap_5f733bc759890 a{ color: #acacae; }#iguru_soc_icon_wrap_5f733bc759890 a:hover{ color: #ffffff; }