Learn Software Development » Software

Scrum problem – Making sure that the Product Owner is empowered to take decisions, especially the tough ones

ashish — Tue, 22 Mar 2011 19:08:33 +0000

In a typical organizational structure of a product development organization, the Product Manager has a fairly powerful role. It is the Product Manager who looks at the features that are to make it into the Product. This is done based on various factors such as competitor analysis, various interactions with customers and industry experts, analysis of new technology trends, as well as some imaginative ideas for new features and customer interactions. Now, when you have all these factors, it is difficult to make the exact decision of which feature will have higher priority; and that is where the Product Manager makes the decisions about which feature is most important (or which set of features are the most important). The team depends on the expertise of the Product Manager to take such decisions, given that it is the product manager who is in maximum contact with the customer base and the industry.
When you get to the role of the Product Owner in Scrum, the role envisions a person who represents the customer and the requirements, but also works on close conjunction with the engineering team, typically spending much more time with the team. As a result, because there was no increase in the number of people working on the Product Manager / Product Owner role, we were able to see that there were time issues in terms of being able to spend more time with the customer base and with various industry associations (the time available for this was much less than in the earlier development methodology).
Because of this, in one specific case, we could see that several stakeholders were somewhat hesitant about how much authority to give to the Product Owner, considering him somewhat tainted with a much higher degree of exposure to the development. As a result, a senior Product Manager type of role was also brought into the picture to oversee (more of a consultative nature); but the net result was that there was a resultant image perception that the Product Owner was more relevant to help the Product team and the senior manager was the person who had the clout to take the different decisions. So, when there was a case where the Product Owner decided to decline one of the features that the team had built and wanted to focus the team on another direction (because of feedback from an early set of users), the team actually wanted the senior manager to listen to them and then finally take a decision.
This was a very dangerous situation, since the entire authority of the Product Owner was at risk. We had to ensure that the senior manager declined to listen to the team (since he was deeply involved with the Product Owner, he was convinced about the position of the Product Owner), and there was a reinforcement of the authority of the Product Owner to take the required decisions.

Low Hit Ratio for Scrum – needs work from the team working on this

ashish — Mon, 23 Aug 2010 18:49:54 +0000

Scrum is an iterative, incremental framework for project management and agile software development. Rather than full process or methodology, it is a framework. Instead of providing complete, detailed description of how everything is to be done on the project, much is left to the team. This is done because the team will best know how to solve its problem. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as general project/program management approach.
The Scrum approach is sometimes compared to rugby, where the whole team tries to go the distance as a unit, passing the ball back and forth. The Scrum Team is self-organizing as there is no overall team leader which decides which person will do which task or how a problem will be solved. The team is cross functional so that everyone necessary to take a feature from idea to implementation is involved. Scrum projects make progress in a series of sprints, which are timed iterations no more than a month. At the start of the sprint, team members commit to delivering some number of features that were listed on the project’s product backlog. At the end of the sprint testing is done and the features are then integrated into the product. At the end of the sprint a sprint review is conducted and feedbacks provided influence the next sprint.
The co-developer of Scrum Ken Schwaber once said, “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it”. He also said that Scrum exposes every inadequacy or dysfunction within the product and system developed practices but many organizations change Scrum to accommodate the deficiencies instead of solving them. But contrary to this comment, it is often seen that the dysfunction exposed by Scrum is often not understood by the teams properly. Whenever dysfunctionality appears it is assumed that the problem is with the team because it is the American way that the people having the problems can pull themselves out of their problems.
It is more often the case that the root cause of blocked flow is somewhere else in the organization even though it is showing at the team level. Hence if teams start with Scrum arbitrarily the companies might not get the values they seek because they are not solving the real problem. And the problems in other areas are typically caused by violating lean principles which most people are not familiar of. The reason for people not being aware of the lean principles is that they are not discussed by most Agile consultants because it is believed that for success with Scrum you don’t need lean. Therefore the reason people accommodate the problems is that they really don’t know how to solve them. So the teams attempting to do Scrum from a team perspective should expect a success rate of only 25% because only part of the time the team will be on the main challenge and it requires a bigger view to view this.

Using VersionOne tool with Scrum

ashish — Mon, 21 Dec 2009 18:09:19 +0000

There are many tools you can use for the purpose of running your Scrum process, with some people even using Excel with a combination of Post-It notes. However, I have found that it makes things more efficient by using a professional tool in the Scrum process. One of the more famous tool in this regard is called VersionOne (website) (of course, VersionOne can be used for other Agile methodologies as well). From the site itself, here are some of the features of VersionOne.
- Built–in support for agile development: Our methodology templates for Scrum, XP, DSDM and Agile UP have “packaged” various Agile practices and principles together in a way that helps guide teams through the process of rapidly planning and delivering working, tested software.
- With V1: Agile Enterprise, organizations have the option to select either an on-demand or an on-site deployment.
- With 60+ agile metrics, reports, and executive dashboards, no other agile management tool provides greater visibility into the progress, status, and health of agile projects.
- V1: Agile Enterprise is extensible via an API, intuitive SDK, and third-party tool integrations.
Learn more with this link.

Some more reviews:
At BrightHub.com (link)
At borisgloger.com (link)
At redmondmag.com (link)
Another article at BrightHub.com (link)

Scrum tool – Scrumedge.com

ashish — Tue, 08 Dec 2009 18:09:18 +0000

Using Scrum can really change the way you run your software business. You can get your team to be more self-empowered, more involved with the project, as well as viewing the semi-finished project on a more regular basis. However, your experience with Scrum is also dependent on the tool that you use – use a tool that is not good for the job and it becomes difficult to keep the morale levels high, as well as not getting the right information to make the important decisions.
One tool that we are looking at today is called ScrumEdge, and to try to get feedback, we will look for some reviews of the tool on the internet.

Details about ScrumEdge (link)
ScrumEdge is a collaborative tool that allows teams, ScrumMasters, and stakeholders to manage the Scrum lifecycle at the product and sprint levels.
In the service industry your hours are your inventory. Lose track of them — they spoil. ScrumEdge gives you the information you need, when you need it. Nail your mark, every time.

Some reviews:
1. ScrumEdge – Review at BrightHub.com (link)

ScrumEdge might be for you if you use the Scrum project management methodology already and are familiar and comfortable with the scrum process. The program is well suited for small and startup businesses wishing to use agile project management methodologies as well as those who are established. Finally, the program is good for those who want software that isn’t as complex as MS Project and its alternatives, but also don’t want anything too simplistic.

2. ScrumEdge on feedmyapp.com (link)

With ScrumEdge you’ll no longer need to deal with shared excel-sheets or walls covered in post-its! The icing on the cake is the ease with which ScrumMasters and Team Members can access their data and view a project’s progress from any location; office, home or even while traveling!

3. ScrumEdge on listio.com (link)

ScrumEdge enables agile development teams to better organize and manage project deliverables, allowing them to deliver high quality products in short time-frames.

System Engineering

ashish — Sun, 25 Oct 2009 05:59:49 +0000

Systems Engineering is an interdisciplinary process that ensures that the customer’s needs are satisfied throughout a system’s entire life cycle. This process is comprised of the following seven tasks.

1. State the problem. Stating the problem is the most important systems engineering task. It entails identifying customers, understanding customer needs, establishing the need for change, discovering requirements and defining system functions.
2. Investigate alternatives. Alternatives are investigated and evaluated based on performance, cost and risk.
3. Model the system. Running models clarifies requirements, reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of efforts.
4. Integrate. Integration means designing interfaces and bringing system elements together so they work as a whole. This requires extensive communication and coordination.
5. Launch the system. Launching the system means running the system and producing outputs — making the system do what it was intended to do.
6. Assess performance. Performance is assessed using evaluation criteria, technical performance measures and measures — measurement is the key. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it.
7. Re-evaluation. Re-evaluation should be a continual and iterative process with many parallel loops.

The purpose of systems engineering is to produce systems that satisfy the customers’ needs, increase the probability of system success, reduce risk and reduce total-life-cycle cost.
Systems engineering, which stands at the interface between engineering and management, is conspicuously practical and down to earth. In contrast, systems theories, which lie at the core of engineering science, are mathematical and rather abstract. This in no way implies that systems theories are impractical; they are practical in a general way. Connecting them to systems engineering is the notion of function, through which systems theories are applied to particular designs.