Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I was reading about the necessary metrics for SCRUM and I couldn't find 'Defect Leakage' listed in there. This is the case even with the papers published by Jeff Sutherland.
I was wondering if there is any reason behind not considering this as an important metric in Agile SCRUM. Does anyone know?
Scrum is a minimal process improvement framework. It very deliberately doesn't talk about any metrics beyond meeting the sprint goal.
If your team find defect leakage a useful metric in helping them improve then they are, of course, allowed to use it. If the management outside of the Scrum team find defect leakage a useful metric - then they're perfectly free to use it too.
Scrum doesn't define the metrics you should use. It allows you to use any that you find effective.
There are no metrics in SCRUM. This doesn't mean you can't have metrics, it just means that SCRUM doesn't mandate them nor tells you what you should do in this case, hence why you aren't finding anything of the sort.
Since we're talking about SCRUM, one usual mindset to this is to ask ourselves:
is it useful? Does this <activity,metric,task> have a big value?
why do i want to do this? What will i get from it?
So instead of looking for the answer, i suggest you answer yourself that.
(PS: my boss asked me to is not the greatest motivational answer)
If you take a look at the Scrum Guide you can see that Remaining Work is only metric mandated as part of the Scrum Framework. As long as you can monitor Remaining Work you are at least looking at that one "thermostat" for your project.
Does that mean that you should not look at anything else? Heck no... as long as you continuously monitor your metric usage and watch for negative impacts on the team and organisation you can monitor whatever you like. Some teams require to do time-sheets for financing while other like to monitor mean-time-to-resolution or build quality. Although after looking up "defect leakage" I would question its usefulness.
p.s. Scrum is a noun and not an anachronism and so does not need capitalised
Scrum should not be set-up as an excuse for bad code or for defect leakage. If there is leakage, that means there will be items being added back into your backlog and unhappy clients. Most teams that I talk to using scrum also try to use techniques from xtreme programming, like test-driven development, junit tests, automated regression test scripts. No matter the tools, you should have QA resrouces booked 100% on the team, who are ultimately accountable for their processes around issue management and the quality of the deliverable that is deployed at the end of each sprint.
Another thought: if defect leakage is a metric expected by the enterprise, you could consider treating it as a criteria on a user story for sprint 0. But, if it's not important to the project or enterprise in general, you probably won't get it from the team during execution, or the team might implement it when problems arise in an adhoc, tactical manner.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
After working Scrum(ish) in a previous workplace, I am trying to implement it in my new place of work for a brand new project (I am no scrum expert). We have some pre-requisites to code before we can begin working on the stories (which are being groomed in the mean time). Things like database design, api design, etc. We plan to use two week iterations and it's just not clear to me how the first one (or two) can provide something useful to the customer and "potentially shippable" if we first have to "lay down some groundwork" ? Any ideas on how to treat this?
What you are experiencing is very typical of new teams wanting to move to Scrum where they are coming from more of a traditional process. Adapting to Scrum is very, very hard and we always say this, and the reason for this is there needs to be many mindset changes.
The first change the team should understand is that when bringing a PBI (requirement) into a Sprint, it only a well defined requirement with nothing else. This means there is no designs, database schemas or API's for the requirement. The team has to do all of this in the sprint, plus build and test the requirement.
If you are new to Scrum, you most probably are squirming in your seat thinking it cannot be done. You are likely right for now, but this is where the hard work comes in ... changing the way teams work. This is hard.
Some pointers :-
Small Requirements - Most teams suffer from poor, ambiguous requirements which previously took days to design, build and test. The art is to learn to break these EPIC requirements down into smaller incremental requirements where each one builds upon the previous, but explicitly adds business value. Now, I am going to be blunt here ... this is the biggest challenge for most teams. Personally, I have been training/coaching Scrum for a number of years now have not found any feature that cannot be broken down into small requirements with an average estimate of 2-3 days to fully complete.
Team composition - The team needs people in it with all the skills necessary to design, build and test the PBI. They should not have dependencies on other people outside of the team. Having dependencies, cripples teams but it highlights to management there are not enough people with the specialised skills.
Sprint Planning - Sprint planning should be used to do high level designs and discuss how the team is going to tackle delivering each requirement. Many teams waste their sprint planning by clarifying weak requirements and debating the requirement. This is a sign of weak requirements and it should be addressed. Sprint planning is about discussing How to build/test a PBI and not What.
Coach - I would really recommend you hire an experienced contract coach/consultant to get you going and do things right. Trying to do this by yourself, just leads to a world of unnecessary pain.
Architecture - At the inception of the project, there is nothing wrong for the team and architects to spend a day or two brainstorming the macro architecture of the product and discussing the technologies to be used. However, when it comes to new requirements they are designed and adjusted into the product. This sounds hard, but with the correct software engineering patterns using SOLID principles, well defined patterns as well as strong Continuous Integration and Unit Testing. The risks of a bad architecture are eliminated. There is not question that the team should have a member in it that has the skills to design an architect the new requirements. [There is lots of evidence on the web that an evolving architecture with re-factoring results in a better application than a big upfront architecture - but that another debate]
Application Lifecycle Management - Invest in strong ALM tooling with CI, unit testing, test lab, continuous deployment. Having the right tools for the team allows you to deliver quickly, and a lack of these totally cripples you. CI with automated testing is essential for an incremental product as there is fast and constant change and you want to protect that a change does not break a previous requirement.
ScrumBut - Ken and Jeff no longer support the use of the term ScrumBut as it is perceived as elitism and often comes across as belittling. Instead it is preferred that teams are on the journey to implementing Scrum and helping them through coaching.
Welcome to your journey into Scrum, hang in there as it is very hard initially. Once you fully "get it", then you and your company will be really happy that you did.
In an ideal world, Technical pre-requisites should be factored into the estimate of each story and you should only implement "just enough" to complete the story. See "Do The Simplest Thing That Could Possibly Work"
Why do you need to design the API or the Database? Try to avoid Big Up front design. Avoid building Frameworks up front, apply YAGNI
It's hard for you to understand how you could ship something in two weeks because you have the cart before the horse; that is, your priorities are wrong. The important thing is delivering customer software - not building databases or API designs.
This is a trade of against long term productivity and you should avoid accruing too much technical debt. Many Agile methodologies would argue that up-front work like this will be wrong and therefore should be avoided to minimise waste. Lean software recommends defering decisions to the Last Responsible Moment.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is there anyone who can tell me what is the difference between CMMI and Agile. I know some obvious difference, but I want to know it further. I will appreciate it a lot if someone can help me! Thanks!
CMMI is a process improvement methodology which aims to take projects or teams from level 1, "chaotic", to a higher level, ideally but not necessarily level 5, "optimising".
It consists of various capabilities, each of which is assigned to a specific level. For example, CMM level 2 requires the Project Planning capability. The levels are basically:
Chaotic, no real control.
Managed, processes at project level, mostly reactive.
Defined, processes at organisation level, proactive.
Quantitative, processes measured and controlled.
Optimising, feedback loops and continuously improving.
In my opinion, high levels of CMMI maturity are rather complex and difficult to achieve. While working for a large company doing outsourcing for a major Telco, we achieved level 5 but it was a great deal of work for continuously diminishing returns. We ended up viewing it as mostly a way to get government work and, in fact, I made a name for myself as a small projects specialist where we could still follow CMMI but not have to charge megabucks to the customer.
Agile, on the other hand, is a project management methodology focusing more on delivering what customers need rather than copious amounts of paperwork :-)
I see CMMI as one level up from Agile in that Agile itself is not a massively self-improving process.
It has improvement processes built in (such as retrospectives) but not in such a manner that the whole methodology may be turfed out if it's not performing.
In higher CMMI levels, whole chunks of project management methods (including Agile for example) can be tossed out or bought in depending on their performance and/or likely efficiencies.
Agile is a set of four main principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
—Agile Manifesto
From which dozens of software development methodologies are derived.
CMMI is a process improvement model. It's a meta-process and it's not, AFAIK, strictly related to software development.
As such it makes absolutely no sense comparing the two (a model and a set of principles). It also makes no sense asking about which maturity level is agile or even which maturity level is a specific agile methodology.
We can only talk about the specific maturity level of a particular agile software methodology implementation, e.g. "in this team we do Scrum at an optimizing maturity level".
Some great formal answers are already here, maybe this will help to understand the difference for ones who seek understanding:
On a pirate ship set of principles that keep pirates moving towards a common goal is called "pirate code of honor" - this is set of Agile principles.
But there is always one guy on a boat with navigational instruments and a map, who knows where we are now and how to guide the ship through the seas - this is CMMI.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.
Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?
I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.
Your individual work-products would gain the same advantages that teams gain with scrum:
You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
Your estimation technique will start to improve with reflection and retrospectives
You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.
You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.
And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.
I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.
Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.
For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.
Even if it's just you in the daily stand-up, it can be scrum.
If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.
I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.
G'day,
For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.
HTH
cheers,
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So I find myself working for a few weeks in a small team of four, including me. Quite a change from my last job at a 300+ developer shop where I'd been part of the adoption of an agile methodology.
I've been sneakily introducing useful tools like a continuous integration server and am surreptitiously starting test-driven development.
What other agile project management and development practices are appropriate for the smaller shop?
Well, to me, your actual configuration is much more appropriated for Agile than a 300+ developer shop (not really sure how Agile was implemented there, I'd love to hear more about that as scaling to that size requires a very high level of maturity on Agile IMO).
So, my answer would actually be: starting with 4 people, all values and practices are appropriate and valuable. Actually, what Agile methodology did you adopt previously? What practices did you implement? What makes you think they wouldn't be appropriate?
PS: If I may, try to see beyond engineering practices, Agile is not (just) about that (this is especially true for Scrum). Practices such as Test Driven Development, Continuous Integration, etc are nice but they are just a mean, not an end. They won't suffice for a successful Agile implementation. Agile is a business oriented organizational pattern. In other words, technical stuff is not really the best starting point when implementing Scrum, you should start with organizational things.
IMHO all of the development practices are appropriate. In fact, for a long time an agile team was expected to be a small teams (5-9 people). There is an artile of infoq about it.
Also, because you have a small team both communication and collaboration will become easier, so the practices would work even better.
Focus on introducing practices that add the most value to the team.
As the team is small impact of the change will be highly visible, if you work with the team and show improvements then you can go back and add another one - again the one that add the most value to the team.
One of the most important thing is that the projects are approached with an agile mindset, adding tools & techniques in the context of long projects that can't adapt to change & are not highly tuned with the customer won't have the ultimate result that you should be aiming for.
Communal code-review whether or not everyone is on the same site
I think you may want to flip the question around; what agile methods would not be suitable because you are a small team. I am no expert in agile practices, but I can't really think of any that would not be appropriate because of your team size.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I read a lot of books about what practices work well or not in software development.
And I have NEVER heard about methodoly like ITIL or CMMI in any webcast or book or blogs in the development field.
I have heard about these methodologies in my school, and to me it seems to be bureaucratic practices.
However every books on development I've read talk about collaboration, or people over documentation. (Yes, lots of agile books)
So my question is : Does methodologies like ITIL or CMMI have some impact or relation with development or the everyday life of the developer ? And do you have great books or blogs which talk about some good ideas in these metodologies I can use on a development team ?
ITIL is more focused on the infrastructure and support side and not development, so discussion of ITIL is probably more appropriate on the "IT" focused version of StackOverflow that is supposedly in development. As an aside, I take exception with calling that other site "IT" focused as IT encompasses infrastructure, support, and development in most enterprises...probably a good percentage of StackOverflow users are developers in IT departments.
I've worked with CMMI and the Team Software Process (TSP), both products of Watts Humphrey and the Carnegie Mellon Software Engineering Institute. If you are committed to continuous improvement and believe that measurement is at the heart of any continuous improvement, then you will find value in CMMI.
It is very easy to do CMMI (and TSP) wrong or in a way that alienates developers and ultimately ends up as window dressing or something that looks good on a pile of certifications. Look at the development vendors in India...they are miraculously all CMMI level 5. What they don't tell you is that was almost always one small project or team in their organization that worked hard to get the certification, but the repeatable practices are simply not there for 95% of their organization.
The focus on time tracking (clock punching), defect tracking (bug quotas), lines of code (lots of ways to "game" if you are so inclined), and making your process repeatable (making a developer feel like a cog with no freedom to innovate) turn off many developers. <-- note the jaded counter-arguments in parentheses.
The fact remains that 90% of the developers out there (few of which read StackOverflow or any technical blogs/web sites) shoot from the hip and are sorely lacking in self-awareness of where their opportunities to improve reside. For them, the process rigor and opportunity to make incremental improvements in quality through the self-awareness that repetition and measurement facilitate are valuable components of CMMI.
Done right, you get the same benefits from Agile methods like Scrum where again the focus is on repeatable iterations, learning from each iteration, and improving/narrowing in on your goal. It takes a lot of maturity and experience to lead a team in adopting either Agile methods or CMMI and get full value out of them.
Agile is sexy and CMMI is about as far from sexy as you can get, which is why you don't hear about it as much.
Agile adoption tends to be bottom-up: techies stumble upon it and recommend it to management.
ITIL/CMMI tends to be top-down: management stumbles upon it and pushes it down to techies.
That doesn't make one good and the other bad; mostly that affects the language used to describe each approach. And there are plenty of exceptions - people with experience in the trenches who are good at applying CMMI, and managers who grok agile.
Google for "agile CMMI" and you will get many hits. I prefer not to recommend one in particular, because it's an ongoing debate (i.e. some of these folks are just plain wrong).
In my view, the notion of process is certainly a useful idea to have when analyzing day-to-day software development work. The idea that there are some recurring activities, and that these activities are often organized in similar sequences, is a good entry point for asking questions that lead to improvement. You can also get some mileage by asking what is repeatable and under what conditions activities can be called managed.
The error and the excesses begin when magical thinking sets in: "If we just describe (on paper) the Perfect Process and document it accurately, people will follow it and we will get perfect software." It doesn't work that way.