Agile Development in 3 Simple Steps

Why should we work with Scrum Methodology in our company?

Here are a few reasons why Scrum works:

1) Emphasis on communication.

Scrum promotes communication between our project team members, as well as between our clients and us. It also promotes a good team work attitude.

2) Quick results.

On average, a couple of iterations (sprints) is sufficient to show a working product to the client. This way, we get early feedback which helps shape the work ahead.

3) Focus on what is important.

Since all the items are prioritised based on their business value, no time is wasted developing what is not important.

4) Fair time estimates.

Since the production team is involved in the estimating of the Product Backlog cards, the overall time estimate is fair and square (accurate).

5) Self organisation.

The production team is a self-organised unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow. The ideal Scrum team formation is a subject for another post.

6) Transparency.

Scrum promotes transparency: the client knows what is going to be delivered in the sprint, since he/she has prioritised the Product Backlog. There is also a great deal of transparency within the production team during the Sprint. The entire sprint backlog is available to all team members.
                                           

Management 3.0 - From the book "How to change the world" by Jurgen Appelo

Complexity Thinking

Simple models, supported by inspiring stories, are good to get you started
with the basics of change management. The real world, however, is far more
complex than what most models would have you believe. We need a more
complete approach to organizational change. It is very hard to predict how a
complex social system will behave. We need to understand how to influence
the whole system by poking at it. Then we see how it responds. As change
agents we try to nudge people, teams and organizations so that they will
reorganize themselves.

“ The trick, as with all the behavioral possibilities of complex
systems, is to recognize what structures contain which latent
behaviors, and what conditions release those behaviors - and,
where possible, to arrange the structures and conditions to reduce
the probability of destructive behaviors and to encourage the
possibility of beneficial ones.

- Donella H. Meadows, Thinking in Systems.

Evolution of Management

Management 1.0:  Doing the wrong thing

Management 2.0:  Doing the right thing in the wrong way. 

Management 3.0:  Doing the right thing 

"Jurgen Appelo"

A Scrum Master Is Not a Project Manager

Contrary to popular belief, the ScrumMaster and project manager roles are highly different and shouldn't be confused. As more companies migrate their project management to Agile, many do so without a proper understanding of what they're aiming for. In particular, there are incorrect assumptions made about the roles in Agile; people often expect that the shift from Waterfall practices includes a wholesale shift of roles. The ScrumMaster, however, does not play the part of the traditional project manager. In fact, the ScrumMaster is an entirely new role. (If you're looking for the project manager within Agile, you'd be better off looking to the product owner.)

 Who does what?

Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The ScrumMaster's role is more that of coach and facilitator, a role that sits between the project and the customer. The ScrumMaster doesn't manage the team that produces the work; instead, he supports the product owner, coaches the team, and makes sure that Scrum processes are adhered to. The ScrumMaster is responsible for the Scrum process, its correct and continuous implementation, and the maximization of its benefits.

Product owners have a huge responsibility for the project — their project. They're responsible for maintaining a product backlog that describes the product and continues to fit with the requirements of the business. During any project, as more becomes known about a product, about customers, or about changes in the market, a product may need to change in order to meet these requirements. The product owner has to adjust and reprioritize the backlog to fit these changes and steer the project. With many projects, that's a big task, one that many product owners struggle with — and occasionally avoid.

The ScrumMaster is there to help, coach, provide a consultancy role, and look at the project from all angles. The project remains the responsibility of the product owner, and it's up to him or her to make the final decisions. However, the product owner can look to the ScrumMaster to help answer questions about user experience, functionality issues, user feedback, and any need to realign the development to fit with changes outside the business. The ScrumMaster helps the product owner understand how to effectively manage the work of the team, using the product backlog and the planning and review meetings.

ScrumMasters can come from project management, but that's not a guaranteed fit. Business analysts and team members can also fit the role. A lot of traditional project managers (PMs) struggle with the transition because it means stepping away from a highly structured position: one with them at the helm, steering the development and the team toward a predefined specification. The often overwhelming change controls imposed in traditional Waterfall approaches are no longer there to protect the PM from the risks associated with change. Gone is the overanalyzing, form-filling approach to change. The product owner often now has to deal with change on a daily basis. Those changes aren't always big shifts, but the decisions made to include them can have a big effect on the end product. Being able to make those decisions is important to the flow of the project, and a product definition may change massively from what it looked like at the beginning. In fact, a product doesn't even need to be fully defined at the outset of an Agile project. That scares the pants off many traditionalists!

 

The coach, mentor, and Scrum guardian

This is where the ScrumMaster plays a vital role. While Agile is becoming a part of many projects, there are still those who shy away from it, are nervous about it, or just don't trust it. They find the traditional PM role far easier to understand. What they don't realize are the restrictions imposed by the old role and approach. The ScrumMaster has to coach the product owner to understand how to achieve the goals and how to continually adapt and prioritize the backlog. The ScrumMaster is the link between the product owner and the team.

The team, depending on its level of experience, may also look for guidance and help in solving issues and blockers. The ScrumMaster needs to steer the development through these issues, resolve any problems that are blocking the development, and involve those with the needed skills and experience. There is often a lot of noise from within the business, and it's down to the product owner and the ScrumMaster to protect the team from that noise. Changes in what is being developed should be communicated via the product owner and nobody else.

As a project progresses, the product evolves. What might have been expected at the start of the project is not necessarily what we produce. User feedback, for many products, is essential for defining a good, solid, usable product. Organizing product reviews and dealing with feedback from users is imperative for the success of a project and the product it's producing. It's really not enough to produce a product that the client thought was needed. In order for a product to work, there has to be feedback from a wider audience. Its experiences and feedback need to be managed through the product backlog (provided the product owner considers them suitable for the product). Again, the ScrumMaster can help facilitate these changes by helping the product owner describe them, understand their impact on the product, communicate them to the team, and prioritize them in the backlog.

 

The ScrumMaster is not a lead developer

The team tasked with developing the product has a huge responsibility. It's required to understand the requirements, break them down, and then accurately estimate, produce, and finally demonstrate the output. The ScrumMaster needs to help the team by facilitating the reviews and planning sessions, but he or she isn't there to manage. The team is responsible for managing itself. In most teams there is a lead, generally the most experienced member, who steers the team, reviews proposed solutions, and makes decisions. The ScrumMaster is there to support the team and provide input and support when required.

There are teams, particularly in software development, who find it difficult to differentiate between the ScrumMaster and the lead developer. Often a the team needs a development lead who has particular skills and experience and is able to manage the team and make its decisions. This is not a ScrumMaster role; it is specifically a role required within the team. It's up to the team to lead itself, either with a lead role or a collective togetherness.

This leads some to think that the ScrumMaster role is not required — but that's not the case. The roles are entirely different. The ScrumMaster is there to facilitate, coach, and provide support. If the project requires someone within the team who can manage, lead, and take responsibility for the development, then that needs to be defined by the project. That lead role should be allowed to concentrate on the development and produce a product to the best of the team's ability. The lead should not be distracted by the wider project or the broader considerations of the organization.

 

ScrumMaster summary

So remember: The ScrumMaster is likely to be someone you've not met before if you're from a more traditional background. He or she is a facilitator and a coach but isn't responsible for the project or managing the development team. If you have questions about the product being developed or you want to contribute to the product, then the product owner is the one whom you need to look for. If the ScrumMaster is making decisions about a product, then Scrum has not been properly implemented and there's going to be confusion and conflict about who does and owns what.

There you have it: The ScrumMaster is an entirely different role from that of the project manager or the lead developer. You can be a ScrumMaster and a project manager — but only on separate projects.

An Agile project is defined by the product owner and developed by the team. The ScrumMaster is there to facilitate, make sure that Agile processes are being followed, and support the product owner and the team.

It sounds like a cushy job, but it requires particular skills and experience, and it takes the right person to make it work.

           

                                                By "Steve Hunton"

The Product Owner - Responsibilities

The Product owner (or Agile PM) shoulders all the responsibility for Project success and is ultimately responsible to the Team, stakeholders and to the company. With so much at stake it's easy to get bogged down or revert back to old ways and the whole team suffers as a result. In order for Scrum to work the Product owner has to focus his time on activities that matter.

1. Creates and MAINTAINS the Product Backlog. I emphasize MAINTAINS as this is an on-going job and more than likely a full-time activity. Nothing is constant in the world of software and it’s important that the Product Owner keeps his/her eye on the ball. Note: the Product Backlog must be groomed prior to the Sprint Planning Meeting in order for the team to remain productive.

2. Prioritizes and sequences the Backlog according to business value or ROI (there are lots of tools to help Product Owners do this and lots of books on the subject) The Product Owner is required to have the Backlog sequenced prior to the Sprint Planning Meeting. This means that each user story must be ordered by relative importance. It’s no good to have 5 high priority or 5 medium priorities. It’s important to know which User story is #1, which is #2 etc.

3. Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint. User Stories are elaborated at the last responsible moment and it is the Product Owners responsibility to be there during the Sprint Planning meeting to help the teams to understand exactly what is required.

4. Conveys the Vision and Goals at the beginning of every Release and Sprint. The Product Owner must continuously remind the Team of the Sprint and Release goals. This helps to keep the team on track and serves as an over-arching yardstick for the team to measure their activity and progress against.

5. Represents the customer, interfaces and engages the customer. The Product Owner must continuously engage the customer and stakeholders to ensure the Team is building the right product and therefore delivering the ROI expected of it. The Product Owner has the opportunity to steer the team in a different direction at the end of every Sprint, so he/she must be ready to do just that if necessary.

6. Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives. There’s always a lot going on and always an excuse to miss the meetings. But each of these Scrum ceremonies is another chance for the Product Owner to inspect and adapt. And as a result being present at these ceremonies is tantamount to success.

7. Inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done. Work that is either not complete or un-done needs to be re-prioritized or sequenced. An Agile PM is one who is quick to recognize and understand change and to ensure the Product Team adapts to the change in landscape, be it competition, target market or other.

8. Can change the course of the project at the end of every Sprint (30 days if you’re following traditional Scrum methodology by the book). The Product Owner is in complete control and can steer the team in a completely different direction at Sprint boundaries. And good Agile teams will welcome this change as long as the Product Owner is confident and knowledgeable.

9. Communicates status externally. The product owner is the voice of the Team to the outside world and should ensure that all channels of communications are open and that projects have the right amount of support required to succeed.

10. Terminates a Sprint if it is determined that a drastic change in direction is requirede.g. a competitor releases a new version which demands a counter response. This is a pretty serious event for Scrum teams. And what this means “technically” is that all work done up until that point is lost. I have not seen this done to many times in my career especially since, there’s really not that much time between Sprints in any event.

The responsibilities of the Product Owner are onerous and there is no one else on the team to cover for him/her or pick up the slack. So if you’re choosing a Product Owner, choose wisely, the difference can be success or failure for the entire project or, in the worst of circumstances, the success or failure of the company.

Written by: Jack Milunksy 

Leading Agile Developers, Developing Agile Leaders

Agile management is an often overlooked part of Agile. There are at least a hundred books for agile developers and project managers, but very few for agile managers and leaders.

However, when organizations adopt agile software development, not only developers and project managers need to learn new practices. Development managers and team leaders must also learn a different approach to leading and managing organizations.

Several studies indicate that management is the biggest obstacle in transitions to agile software development. Managers need to learn what their new role is in software development organizations in the 21st century, and how to get the best out of Agile. 

                                                                  "Jurgen Appelo"

Differences between Waterfall, Iterative Waterfall, Scrum and Lean Software Development 

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart –you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

• You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
• You leave the testing until the end, which means you’re leaving issue discovery until late in the day
• You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
• You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
• You’re heavily reliant upon a project manager driving the way – the power of one
• 
  

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still farmore risky and less efficient than a more Agile approaches. The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features. The most commonly occurring issue in this type of scenario (in my experience) isbottle necking. For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way.  You’re more or lessforced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches. We focus on delivering fully-tested, independent, valuable, small features. As such, wediversify our risk – if one feature goes wrong, it should not impact another feature. With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again. In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level. In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

Scrum vs Kanban

Scrum vs Kanban

SCRUM BOARDS

Scrum boards are for teams who like to plan their work in detail before they start a project. This usually includes creating sprints and giving story points to user stories in order to plan which story can go to which sprint. When you first create a Scrum board, you create a list of items which becomes the backlog. From there, you create different versions and sprints and move the issue from backlogs to sprints.

Scrum boards have a Plan mode and a Work mode. The Plan mode, as explained above, includes moving issues from backlogs and giving each one a time estimate. The Work mode is the actual board itself, where you can move cards (issues) across columns (statuses).

KANBAN BOARDS

Kanban by contrast allows users to start work without necessarily having a structured plan, and in fact does not even have a plan mode. The Kanban work board uses the same column-based interface as Scrum for tracking the status of tasks, however without the ability to organize these into sprints. This board will deal will all the issues in the project rather than a portion of them.

Comparison

Scrum	Kanban
Backlog This is where the team will plan sprints and estimate stories that will go into each sprint	Workflow You can map columns to the statuses of your workflow. This can also be changed in the future if the workflow changes, by simply adding or removing columns as required.
Sprint Planning Usually when planning sprints in a PMO department, the BA and the PM will sit with the developers and ask for their estimates. This information can be entered directly into JIRA Agile.	Swimlanes This are a very good tool for separating and organizing issues. One example can be to separate issues by assignees. This way you can see how many issues have been assigned to each developer
Agile Board This is the Work mode, where you can see the board itself broken down into different statuses. This allows the team to see the progress of sprints	Constraints You can limit the minimum and maximum number of issues that should be displayed in each status. This will change the colour and make it obvious for the team to decide to whether to increase or decrese the number of issues.
Reports With Scrum boards, you can see many types of reports even while you are in the middle of the sprint. Burndown Chart – check the team progress towards their commitment. If the scope has changed while the sprint is still on, this will also be reflected here. Other charts include: Sprint Report, Epic Report, Velocity Chart, Version Report etc	Reports Kanban also allows teams to view reports. One chart that is quite useful with Kanban is the Control Chart.This will allow you to measure the cycle time for issues. For example, showing the mean time and actual time taken to complete issues.
Scrum+Kanban This board allows you to apply to most basic Kanban principles to improve the flow of stories.

Scrum Agile Development in 3 Simple Steps