search back preload
Unified Blog
Why do we need Scrum?
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Tuesday, 06 November 2012 16:05

Scrum stands on completely different assumptions than the current methodologies. It’s based on the empirical process control model rather than the traditional defined process control model. Then, if Scrum goes against all the established foundations, why do we need it?

Systems development projects used to be predictable until the 1980’s. Since then, they began to be used for competitive advantage.

“Certainty and reliability have been traded for competitive advantage. If too much time is spent thinking through requirements, competition gets to the market first”, explain Ken Schwaber and Mike Beedle in their book “Agile Software Development with Scrum”.
BLINDTEAM

As a result, avalanches of technologies have been flooding the market since, one technology following another in a fast peace, many of them replacing their predecessors before they were fully understood. Systems became complex, variable.

 Unpredictability in systems development is mainly based on requirements, technology and people. If the product requirements are well   understood, the development team works as a unit and it knows precisely how to build the desired requirements into the product using the selected technology, the work proceeds smoothly, with few mistakes.                                      

Unfortunately, projects seldom follow this path. Usually, the requirements are partially understood or still emergent, the technology is arising and has not been fully tested, and the teams’ members need to learn how to work together.

Scrum always expects the unexpected. Its philosophy relies in the assumption that almost any activity in systems development generates the same outcome. Scrum is exercised by frequent inspection and adaptive response. Its simplicity and adaptability is what makes Scrum the best solution for today’s cumbersome systems development.

Last Updated on Tuesday, 06 November 2012 16:23
 
Managing a Release
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Wednesday, 31 October 2012 15:08

                                              THUMBSUP

Product releases occur to meet or excel customers’ expectations and market needs, as simply as that. Each release has to balance cost, functionality, quality, and release date.

In the traditional approach, management needs to know exactly what it’s going to get from a particular project, its budget and the delivery date. But we already know Scrum, and there is nothing traditional about it! As work progresses and the team, the Scrum Master and the Product Owner are more familiar with project’s requirements and technology, the Scrum Master will probably have to trade off functionality, cost, quality and time.

In a perfect world, projects should behave as we expect them to; unfortunately, we don’t live in a perfect world. The Product Backlog might not reduce itself as quickly as expected because the technology is too difficult, the domain is too complicated for the developers to understand, or the functionality was underestimated, to consider a few possibilities. That’s why it’s so imperative that the Scrum Master negotiates with the customer cost, functionality, quality and date, as long development proceeds.

Sometimes, the Scrum Master agrees to impossible delivery dates or functionality just to please the Product Owner, but this course of action usually backfires when the team cannot meet his or her expectations. The best option for management is always maintain a transparent and honest relationship with customers.

Management, don’t be afraid of adjusting time, cost, quality and functionality more than once during a release, life is full of surprises and projects behave the same way; the empirical nature of Scrum will give you all the resources you need to guarantee product release success.

Last Updated on Friday, 09 November 2012 15:19
 
Managing a Sprint
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Monday, 29 October 2012 20:06

During each Sprint, the Scrum Master is the one in charge to help the team to accomplish its Sprint goal, by removing any existing impediment and making smart decisions. In addition, the Scrum Master monitors its work until the end of the Sprint.

If the team doesn’t seem able to finish on time all the selected Sprint Backlog because of an incorrect estimation, issues with the technology or any other reason, the Scrum Master must reduce the team’s work to still meet the Sprint goal. If this is not enough, then he or she might consider reformulating or even cancelling the Sprint.

Once the team, the Scrum Master and the Product Owner get more familiar working together, they will estimate better and therefore, meet the Sprint goal easier.

An intelligent way to track the team’s progress is through the Sprint Backlog graph. In this graph, work remaining and date are the two variables to consider, with the goal to reach zero work remaining by the end of the Sprint.

The Sprint Backlog graph doesn’t measure the time worked by the team to meet the Sprint goal; Scrum is result oriented, not process oriented.

  BURNDOWN

At the graph, every diamond represents the sum of estimated work remaining for all the Sprint Backlog for each day.

In this case, the team didn’t update any of its completed work until September 23rd; this usually occurs to newly created Scrum teams. It’s vital that every team member understands the importance of keeping track of each task they perform, and maintain the amount of work remaining up-to-date.

Starting on the 24th, the team periodically reduced its work until completion on October 25th, when the remaining work reached zero and the Sprint goal was met.

In conclusion, what truly matters when managing a Sprint is that the team accomplishes or excels its goal by the end of the Sprint.

Last Updated on Monday, 29 October 2012 20:16
 
Empirical Management
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Saturday, 27 October 2012 15:34

                                         EMPIRICALMANAGEMENT

Management that employs Scrum has two main responsibilities: do anything in its hands to increase team’s productivity and adapt to the results.

Scrum is, by definition, dynamic, therefore, management must be it too. As the Sprint evolves, management needs to focus on making the team as productive as possible, removing any impediment that may appear. It should carefully study the team through every Sprint, in order to take smart decisions that will make the next Sprint much better.

If the team is unable to deliver the expected Sprint Backlog, then management should reduce the functionality to be deliver or minimize some of its capabilities. Does the team needs an expert, or another team to support them? Management needs to embrace flexibility and adaptability to help the team.

When implementing Scrum, management must actively and wisely participate during the whole project’s development lifecycle to help the team to boost project’s business value. Nothing is more imperative. Management must be in the front line, leading the team to victory.

Last Updated on Saturday, 27 October 2012 15:38
 
Scrum is all about Collaboration
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Saturday, 27 October 2012 14:01

                                         TEAMCOLLABORATION

For someone that is unfamiliar with Scrum practices, this new approach can be quite scary.

How do I know what to expect? How can I delegate all the responsibility to the team? What if they become lazy, and let the customers and the company down? How do I know that the delivered functionality is working as it’s supposed to?

What a newly-Scrum person doesn’t realize is that Scrum does control projects’ development by active management involvement. How?

In a traditional approach, the development organization estimates the cost and the system is implemented, but customers won’t be able to verify the business value they expected until several months had passed.

Scrum demands much more collaboration between customers, investors and the development team. The Product Owner, the Scrum Master and the team builds an initial vision of all the functionality the Product Owner needs, known as the Product Backlog. The rest of the functionality emerges as long the product emerges.

Then, the team delivers functionality every 2 to 4 weeks; this period is known as Sprint. At the end of each Sprint, the Product Owner, the Scrum Master and the team meets to discuss the delivered product increment and what should be developed next. Scrum practices provide control to management on regular basis.

Management is usually so pleased with the progress and the product delivered that, after three or four Sprints, they want to budget for more functionality.

What it’s great about this close collaboration between management, Scrum Master and the development team is that they all work towards the same objectives and views of what customers need. Success is guaranteed, no doubts about it!

Last Updated on Saturday, 27 October 2012 14:12
 
<< Start < Prev 1 2 3 4 5 6 7 Next > End >>

RSS-header

RSS-bottom