Hot answers tagged

14

Building only a user interface prototype will not usually reduce risk. It may increase risk because it would not deliver a working product. The better approach is usually to do whatever you need to deliver a working feature or features in a single iteration, which is what Mike Cohn suggests. Don't confuse uncertainty with delivery risk. Uncertainty is normal ...


11

I think the timing is important. During the daily scrum, he needs to focus on the "what". During the rest of the day, if he feels his experience (to juniors) is valuable, then there's no reason to stop him from dispensing valuable advice. But he cannot pollute the daily. Once he has to "walk around" to dispense his advise individually, he ...


7

Building the entire user interface before building the API isn't the only approach to reduce uncertainty. Another option would be to use wireframes and mockups of an appropriate level of fidelity, perhaps even increasing levels of fidelity, to get feedback from users. In parallel to this, the development team can build vertical slices of functionality, ...


5

With a team of four working on several different products you could consider using a Kanban-based approach instead of Scrum. Scrum works best if you have a cross-functional team with a quantity of work for a single product that makes it necessary to plan a co-ordinated sprint a week or two in advance. With your team however, prioritisation is presumably much ...


5

When you use sprints to develop software, the idea is that after each sprint you should have some new - working - version of your application. You incrementally add something useful to the product with each iteration, it's not just about organizing work. What Mike Cohn is saying there is related to the difference between vertical and horizontal development. ...


4

This is a problem with a simple solution which unfortunately is hard to implement. It's simple because the PO just needs to change his style from hand holding or making decisions for the team, or being prescriptive, to someone that acts more like a coach and mostly focuses on asks "the right questions" so that people figure out things by themselves....


4

The purpose of a board is not to give credit to developers. The purpose of a board, especially a Kanban board, is to visualize the workflow. In this particular case, I see a few possibilities. However, without a full understanding of your workflow, I'm not sure that I can recommend one particular approach. One approach is to create a "release board"...


4

I'm not seeing a contradiction here. First, Scrum requires a predictable cadence. The cadence of Scrum is the Sprint, which begins with Sprint Planning and ends with Sprint Review and Sprint Retrospective. The length of a Sprint is generally fixed. Although it is possible to change the length of the team's Sprints based on stakeholder feedback or ...


2

That you have a "predictable cadence" did not mean you have a predictable output of PBIs. The cadence is the time framework, tells you when you will do which scrum events. Starting from the dailies up to the retrospective. It may happen that you will not achieve (some) of your sprint goals but it should not happen permanently. If you permanently ...


2

Through its events (the sprint itself, planning, daily, review, and retrospective), Scrum does indeed provide a cadence for the team to do the work. It is a rhythm that the team uses to do the work. Within this rhythm, the team will develop a velocity. You can then use velocity to make predictions about future progress. Don't confuse the cadence with the ...


2

You might consider using a technique like story mapping. It would also be worth having a conversation with the team about how they define value. With a clearer idea of that you will be better placed to prioritise the backlog.


2

There's quite a few options for handling unplanned work during a sprint. As an agile practitioner, you have a number of approaches. Ideally the development team determines what can and can't be done during a sprint. But if an issue raised by the PO is required to be inserted into the sprint then you can : 1/ Absorb it. 2/ Break up affected stories and ...


2

I would recommend getting the team together to discuss roles and responsibilities. They might list the pros and cons of having somebody in the Product Owner role who has a technical input to the work and also has authority over team members. Ideally, try and think of a way to track if the behaviour is problematic or beneficial. Perhaps a frequent check-up in ...


2

Oddly enough, I did this years ago. The first releasable increment is someone could pick from a few options (windows web server, lamp server, etc) and it would trigger a build. When the build was done, the person was emailed some login and IP info. This was done in a 2-week sprint. The mechanisms that managed builds and customer communications became much ...


1

One thing you might do is get the team members to refine the backlog on their own in advance of sprint planning. They can add sub-tasks and estimate before the meeting. This is obviously not something you would want from a team collaborating on the same bit of work, but in your circumstances it might make sense. Even doing this, I would still encourage the ...


1

I was in a similar position and while being an Agile evangelist, I didn't see any way out in the given situation. So I'll list the issues you have to solve in order to enable your PO to stop with it. You are missing a technical lead While the PO's behavior is making it harder to take technical ownership, he isn't involved full-time in your technical solution....


1

The fact that you say this person "opted in" to the PO role seems like it may be part of the problem. Usually POs do not choose themselves. A PO is usually expected to be a business manager, not a developer or IT management professional. A PO is someone who has responsibility for some business area or product, can make and implement decisions about ...


1

You can introduce the practice (agreement) that the junior devs go to their more experienced colleagues in the team first. Either do this reactively (the juniors have questions) or proactively (a senior sits with a junior beforehand/at appointed moments).


1

Suppose the development team are developing a product for themselves. The PO could easily be in the team. That might not fit the precise definition of Scrum team, but then Agile doesn't say you have to use Scrum. Self-organising teams - so organise in whatever way works.


1

Apart from ashes999 great answer there is one more notable mention of how to introduce Agile into non-IT organization or team. I really like the part about not going with all the buzzwords and working mainly through Agile values perspective. There is a 5 step method according to this post: https://teamhood.com/agile/agile-for-non-it/ Educate people about ...


1

Try to identify the cause of the problem first. I can suggest some possible causes: Sprints are too long. Five to ten working days is a good length for a sprint. The problem with sprints of longer duration is that estimation tends to be harder, the team is more likely to overcommit, do too much context switching and then hit unforeseen problems. Unexpected ...


1

"I see it a lot, but ..." A team should not "embark upon a sprint" as a way of learning how the technology works or how the goal should be achieved. Unfortunately the methodology is fairly silent on how you should account for this very-important task. As the Perl folks like to say, "There's More Than One Way To Do It,™" and ...


1

"Building a new user interface, and getting approval for it," might easily be viewed as a parallel task to the "mainstream feature-release process." For instance, while working on a loss-prevention application for a major retailer, I purposely constructed very-detailed HTML prototypes and arranged for the users to be able to see them ... ...


1

instead to focus on building something which you could fire a 'tracer bullet' through to cover all technical layers of a feature. Split or not to split in layers can't be answered with a pro or contra in general. Such kind of decisions must be taken on base of a lot of conditions you already have decided before. Especially: if you already set up multiple ...


1

The book probably refers to the situation when developers blindly split every task into layers. That doesn't make much sense because next step (usually QA) won't be able to start any of those tasks until all of them are done. So even if you split them - the group of tasks will still be treated as a single unit of work. What you are referring to is creating ...


Only top voted, non community-wiki answers of a minimum length are eligible