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
What are the reporting lines when using SCRUM methodology as compared to a "tranditional" matrix organisation where developers report to development managers, project managers and any other stakeholder at the time?
The point of Agile is to eliminate all the "reporting lines" and pare things down to the essential relationships and nothing more.
Scrum teams are intended to be self-organizing, not have organization imposed on them.
I don’t believe it is the intention of Scrum to define any reporting lines whatsoever, at least not in the formal context. It’s a software development methodology, not an organisational structure approach. Although I often play the role of a Scrum Master and my direct reports do the development, we could conceivably operate with one of the other guys playing the lead role and myself being a developer without it being contrary to the formal construct. Of course this could be interesting in the event of a dispute but for the most part I think Scrum and reporting lines are two independent concepts.
The reporting lines within a Scrum project are dependent on the situation. At a high level the reporting lines for the project might look like this . . .
Team member => Team => Product Owner => Customers/Sponsors.
The team members are accountable to each other, and as such at the very least use the daily standup to bring their team mates up to speed with any issues and problems. Between them they will decide on course corrections, or a plan of action to fix the issue. The ScrumMaster is part of the team, and may decide to take on tasks to facilitate the removal of any impediments that the team runs into, but that does not mean that the team reports to the ScrumMaster.
The team also makes a commitment to the Product Owner (PO) when they agree on the goal and deliverable for the sprints. As such they will allow the PO to provide leadership for the project and let them (the PO) resolve any issues with respect to the clarification, scope of features.
The PO was the original champion for the project and managed to get funding and buy-in from customers and sponsors. As such the PO needs to keep those stakeholders appraised of the projects progress against the plan for delivery and success. The PO needs to ensure that the stakeholders remain satisfied and in the case that something unforseen occurs, confirm that the new plan still meets with the stakeholders buy-in.
My final note is that managers and project managers are still involved, though more indirectly to help the team remove and solve their impediments that are inhibitors to their success.
Related
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 2 years ago.
Improve this question
I am just curious, since for a scrum-enabled development process the Team Leader (TL) role is merged with Scrum Master (SM) role and the team is supposed to be self-motivated, self-organised and self-driven.
Without a Team Leader (and architect!) inside a team - who is making decisions on a future-proof ways on the implementation? Say, which libraries to use, client data-handling, etc.
Based on the scrum concept, such decisions should be made by the team collaboratively or by the individual team member. Chances are they will not be qualified/experienced enough and the decision could cost millions in the years to come (even one or two years perspective).
How in scrum concept is this addressed, please?
Thanks
Scrum is only the delivery process. Technical decision making should be done by relevant responsible people. Those decisions may come after discussions and team meetings. Team members can also participate to these meetings if required. Role of the scrum master is to make sure the backlog items taken into the sprint is delivered. It has nothing to do with technical decision making. (Scrum master is responsible to remove the blockers and make the team move towards the sprint goal) The team can allocate time for architectural decision making or design/redesign process when they take in a task during the planning meeting.
For example, the TL may have a 4 hour task in scrum board to do the design. If this task involves a meeting with the architect, and the architect is offsite, scrum master should take necessary actions to schedule a meeting and make sure this blocker is removed. May be he can arrange a call between them.
Also it is wrong to think technical leader should be the scrum master. Those are two separate roles and may or may not be the same person.
In Scrum there are three roles defined:
Scrum Master
Product Owner
Development Team
The Scrum Master helps the team to follow Scrum and to remove impediments. The Product Owner looks after the backlog of work and prioritises things.
The Development Team does everything else. There are no defined roles in the Development Team, but instead we have capabilities.
For example, the Development Team has a capability to do development. It also has a capability to do testing.
There is nothing to stop a Development Team having a capability to do architecture. For example, it might have a team member who is from an architecture background or perhaps several team members have architecture experience.
As for the Team Leader role, there is no need for that as everyone in Scrum can act as a leader. For example, if somebody in the team is really experienced in database work, they might show leadership when the team is working on database work items.
who is making decisions on a future-proof ways on the implementation?
The team does.
An experienced Scrum team will get together regularly to talk about 'the big picture'. They will think about the future of the implementation, about the way its architecture, etc.
which libraries to use, client data-handling, etc.
Who has experience making decisions on which libraries to use? They might be a good person to suggest an approach on which libraries to use. The team can then discuss it and agree on an approach. The same goes for client data-handling.
This is collaboration. Everyone has a voice and everyone is a potential leader.
Chances are they will not be qualified/experienced enough and the decision could cost millions in the years to come
If the team is concerned that they don't have enough experience to make important decisions then they should raise that as an issue. Some possible solutions include:
Get additional training for team members
Bring somebody into the team with more experience
Use communities of practice to get advice
The Agile Manifesto directly addresses your question in the Principle that mentions self-organizing teams: "The best architectures, requirements, and designs
emerge from self-organizing teams." Relative to the other well-known Agile methods, Scrum perhaps does the best job of trusting "motivated individuals" (per another Principle) to do so using what scientists calls the "group mind." My coaching practice is based on my review of scientific studies related to teamwork. These have shown repeatedly that cross-functional small groups with diverse backgrounds will out-perform a single expert in decision quality over time. Scrum facilitates this by making people plan everybody's work together and holding them accountable to the group through the scrums and Demos.
That doesn't mean you can't have a technical expert like an architect on the team or providing input to the team. I agree with Leni that it's best not to have the technical expert be the SM, as that consolidates too much social power in one role and places further psychological blocks to true self-organization. (Having a full-time SM prevents real self-organization from the social psychology perspective, so I have members rotate the role.) But those experts can serve as advisors by coordinating bottom-up standards development across teams, providing input into user stories, sitting in on various teams' Planning Ceremonies and Demos, etc.
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
We are new to Scrum and part way through the first sprint we have realised that one of the team members (a developer) needs to do some investigation into how navigation should work (from a user perspective) in the application.
So at the end of this investigation we should have a proposal or prototype of how something should work. But it wont have been actually coded in the application.
So my question is, how should we deal with something like this in terms of the sprint planning. I don't really see it as being user story, but what is it, and how is it treated in Scrum? Does something need to be added to the planning board for the investigation?
Thanks
Paul.
Try to treat prototyping like any other requirement as much as possible. Think about what you want to achieve, create a user story, define one ore several tasks and estimate them during sprint planning. Think of the development team being the user in this case. Definitely have it on the planning board and track progress in daily Scrum meetings. If you have problems estimating the tasks, define them as "time-boxed", i.e. with the fixed time budget, to prevent "endless" work without results.
Although you got the solution Just wanted to add something here.
Such prototyping/researching works are termed as Spikes in the Agile world.
Here, the team dedicates some members into such spikes only so much as to understand the feasibility of the user story and be in a position to help the entire team estimate for the user story.
SCRUM is rather an organizational process than a development model, like prototype-driven development. It means that different X-driven-development models can be easily incorporated, like TDD or even prototype-driven (PDD).
To incorporate PDD in SCRUM, one can set several milestones that are prototype versions. SCRUM can be used normally considering each prototype as a whole new project. It is good for a complex prototype.
However, if creating a prototype is very easy, and a single person can do it in one or two sprints worth of time, so it might be useful to retain a prototype-specialist, that, much like the application-specialist, monitors the work of the rest of the team to check consistency with the ultimate goal. However, a prototype specialist can iteratively provide new prototypes, guiding the work of the rest of the team in a practical manner, differently from the application specialist.
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
We are acting Scrum in our department now. But the up level management structure is traditional, such as Project Manager(PM), Development Manager(DM), Team Leader(TL) and Test team leader(TTL).
Team Leader act as a Scrum master, he controls all the things in our team: communicated with PM/DM/TTL, development management... Our PO's responsibility is just maintaining PBL.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum, and they said some Scrum rules are hidebound.
I act as another SM, I want to change the current status.
But I haven't any headship, just is an ordinary developer in our department. Does anyone has this kind of bother too?
Thanks in advance!
I heard a lovely saying once and can't remember who said it. "They want Agile but they don't know what it is - so we give them Agile but we don't know what they want."
It sounds as if this is happening in your company. Someone, somewhere wants the team to use Scrum, but it's not the team.
That must be a difficult job for an SM, especially if you're doing it unofficially! There are some things I can suggest for you. First, learn some basic coaching techniques: positive language, GROW framework and giving and receiving feedback. This will give you some additional tools which are outside of Scrum and support someone in a leadership rather than a management position (even an unofficial SM can become a leader).
Then, don't worry about the actual practices. If someone has mandated Scrum then the team will be forced to do this anyway. Instead, concentrate on the values and principles of Scrum - particularly collaboration, communication and transparency. Help the team to work with each other instead of being silo'd away. You will have to be an example for them. Don't mandate pair programming, but do go over and pair. Don't mandate stand-ups, but do have conversations first thing in the morning and draw in as many people on the team as you can. Look at the principle of "Continuous Improvement". Learn how to do root cause analysis and the 5 Why's so that the team can understand better why things are hard and take action themselves.
I also recommend Mary Lynn Manns and Linda Rising "Fearless Change". This will help you to work out who else could help you.
Finally, I will echo #sjt. Don't commit Scrum suicide. However, if it's something you really want and your company aren't doing it in the right way, don't be afraid to look elsewhere. Learn some of the fundamentals, practice TDD on your own and find a new job.
Whatever you do, good luck! The first step to change is desire.
If you don't have buy in from your other developers its not going to work. Period.
Scrum requires a heap of discipline, especially during the early adoption phase.
I wouldn't be bothered that management don't care for it. If you're free to do the work of developing the software, and all they care about is results, then it shouldn't matter if you happen to have a 10 minute stand up each morning, and plan small chunks of the work into manageable bits, as long as you're hitting the targets they want you to hit.
If you're team isn't on board though, you're going to have a really hard time getting it working, and it will probably fail and cause more impact that not having tried at all.
If you can try to start it in a small project, with a few developers who are on board with the idea, then you can report back to the rest of your development team on how you found it works, what were the benefits and what were the negatives (reflecting is after all an important part of Scrum).
If you want to get your management on board, you might find that after doing a few projects this way you're much better at estimating the time it will take to develop the requirements you've been given by the PMs, hopefully being able to hit deadlines with more accuracy.
Remember, the PMs and BAs can still work in their normal way, once they've handed requirements to you, you're able to build them using Scrum. Its not ideal, but short of having the buy in of everyone, and the ability to speak directly to users and get them to help write user stories, it will be the best you've got.
When asked to estimate the time it will take to complete the project you can apply Scrum techniques. You can break the specifications down into smaller chunks, group them into sprints and develop them accordingly, hopefully yielding better results.
"I act as another SM, I want to change the current status"
Well, that's a good start right there, wanting to change the situation. Although I must say that without the management buy in, it will be tough. Try and arrange an experienced Scrum Speaker or Agile Coach come and do a presentation or workshop at your company which involves all the upper management. Once you have the management believing in Scrum, it will be all downhill from there.
"Team Leader act as a Scrum master, he controls all the things is our team"
This goes against the Self Organized and Self empowering Teams principle in Scrum. A good Scrum Master would empower the Team in a disciplined fashion within the Scrum Rules, to that appropriate level that, the Team should be able to run on it's own. One suggestion is that the Team Leads need to have a different mindset when working as a SM and different one while working as a Senior Developer, there are no Team Leads in a Scrum Team, only Scrum Team members. You cannot assign true leadership, that is a mutual role which can be earned by creating a reputation of helping others and mentoring others. Have them spit time between SM and development duties 30%, 70% or 50-50 or whatever you find appropriate. Command and control could be counter productive for the Team.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum
A Scrum Trainer had told once told me, "Do not commit Scrum Suicide". If your managers do not care about Scrum, don't get fired trying to convince them. Whatever methodology you guys might follow or "not" follow, you have to realise that all this is a business. Your pay check is dependent on your boss's approval, if your boss or manager does not care about Scrum, then don;t do it. If they care about waterfall, Switch to it, do it like you care, but don't do Scrum halfway and call it scrum.
What has worked for me in the past is to identify and communicate pain-points. Certainly, you should never do something because Kent Beck told you to, especially something that will just get you fired. However, some smart people worked at figuring out a set of practices which is cohesive, and divergence from these practices almost always leads to pain points.
As just one example: if you do Scrum where you have a requirements iteration, a design iteration, an implementation iteration, and a testing iteration, this in theory could work but in practice never does. (When it does, it ends up being Waterfall, and the "iteration" notion becomes meaningless.) Pointing out to your boss that you learned something about the requirements while QA was testing might help him realize there's value in getting QA involved in requirements. Or finding risks in the software design by doing a small prototype may help to show why it might help to collapse the design iteration.
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 am a product owner and I am helping setup a themed sprint. To be clear, by themed I mean all the users stories are related or cluster around a common goal. I still have other stories that don't work well in the theme that I want to include. The problem is that when I fragment the vision of a sprint we don't work as well. Any suggestions?
The problem is that when I fragment the vision of a sprint we don't work as well. Any suggestions?
First of all, you and your Team yourself can answer this question, because only you and your Team have the most knowledge about your situation. I know you wish there was a Scrum Manual where you could refer to some page and get the answer but you have to be factual - Scrum's simple framework never suggests that you have themed Sprints. In fact it suggests that the PO prioritize the uncommitted Backlog list of user stories based on their value and ROI, irrespective of themes, as long as the stories follow the I.N.V.E.S.T Principle, and prioritized periodically. Not that there is something wrong with theming, but if it is not working for you or your Team then you have to adapt to something new, that works for you and the Team. Here are some basic suggestions from my side:
Taking a leaf out of another members post I can say that you and your Team, need an ingredient, which is called "Courage"
The SM of the Team, along with you, needs to have the Courage to use the "Inspect and Adapt" principle to find out why fragmenting is not working for the Team.
As long as the Product Backlog is "ready" before you go into Sprint Planning, The Team needs to have Courage to trust you, the PO, in prioritizing the work for them, irrespective of their own wish or desire or way of thinking.
If fragmented Sprints is what will bring most value, then you as the PO need to have the Courage to talk openly to the Team during the Retrospective about why fragmented Sprints is the way to go, and we need to make it work until you guys find an adapted way of working in that fashion.
Lastly Everyone i.e. The Team, the SM and you need to gather the facts and notes from the above discussions, and come to a common consensus and have the courage to try it until you achieve your goals.
Keep in mind, all this needs to be done within the simple Scrum Framework rules stated in the Scrum Guide.
If you have main vision of the sprint it doesn't mean that you can't include user story which is not part of that vision. User stories are included mainly by their business priority not by their theme. So if you have user story with higher priority than your themed stories you should include it. In my opinion, themed sprints make sence only if priorities reflect splitting user stories into themes.
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
We've been using Scrum on a few projects now with varying success and I now have a query relating to documentation.
In Scrum, you obviously have the product backlog ("The application begins by bringing up the last document the user was working with.") and the sprint task backlog ("Implement forgot password screen"). However, in all the examples I have seen, these two items are fairly high level in terms of detail (being designed on fit on a post-it note).
So, where does the detail sit? Let's say the client has some very specific requirements for a stock management screen, or has a complex API that needs to be integrated with on the back end, where is this documented, how and who captures this information? Is it seperate to the backlog but populated on a just-in-time basis or some other way?
Sprint backlog
The sprint backlog is a greatly
detailed document containing
information about how the team is
going to implement the requirements
for the upcoming sprint. Tasks are
broken down into hours with no task
being more than 16 hours. If a task is
greater than 16 hours, it should be
broken down further. Tasks on the
sprint backlog are never assigned,
rather tasks are signed-up for by the
team members as they like.
Detail can sit in a wiki available to the whole team and editable by the whole team.
Not sure if this is as simple as it sounds. We've seen challenges with the detail part as well. Lets say if we're developing on a story that requires capturing simple contact information for lets say a CRM system. I now have the stories from the PO and we went through the sprint planning meeting and understood the first 5 stories that meets our velocity. However its always a struggle on capturing all the details of the conversation, for example how the screen needs to be laid out, what are the 20+ fields you need to have on the screen, can some of these fields lookup information from other tables/views etc.
Who captures those details, should it be the PO or developer and whats the best practice for storing these details. We're right now trying to use wiki's for this, however it becomes an overhead in trying to maintain the action items on who needs to update which details and by when.
My understanding is that specific requirements such as this are handled by the product owner. They will liase with the client during Sprint Planning 2 and update the tasks with specfic requirements as needed - hence why the Product Owner is a optional attendee of the Sprint Planning 2 meeting. This gives you a hybrid of Just-in-Time and Sprint Planning 2 population of the specifics. Anything that isn't satisfied by the time you come to work on the task will be an impediment and should be dealt with a the daily scrum, by the product owner.
As the development is Agile when using Scrum you shouldn't find too much of an issues getting requirements just in time.