How implement company procedures while using scrum?

Question

My manager give me the task to implement new ISO procedures of analysis and design (later it will be of the entire software development cycle) because in the team we don't have any kind of methodology to develop the requested software which tend to be a "developer do what they want thing".

My manager wants to implement SCRUM (I've reading about it, just to have a general idea) but because in SCRUM the steps are iterative the team decide which process will they use (decisions of how gather the requirements, how design x UI, how you should program), I'm feeling that it conflicts with having a technical procedure of how the things should be done.

Questions

1. Is there a general requirement discovering in SCRUM? Like interviews, surveys with the client and then those stack of requirements are shared with the team in the multiple sprint meetings for the backlog or it's a continue discovering with the team and the stakeholders (users stories in the sprint meetings)

2. I have to create a design procedure, which will describe how to approach UI design (mockups, prototype, etc), in SCRUM is not up to the team how they do it?

An analyst will follow this procedures and after a view of what the project is going to be share it with the team to begin the implementation, though removing the responsibility of recreating the entire development process for each application without an specific methodology.

I know the questions are not specific to the main question, however the answers of them will help me to find an answer.

I'm not going for any certifications, all the procedures in the company are made with the standard ISO 27001, but I'm more in a draft process with trial and error.

What the management want is an established procedures of how the development cycle will be, which I found a little difficult to merge with the AGILE/SCRUM methodology (maybe I need to research more about it) because things as flow as the work is evolved and put persons over process.

Answer 1

Scrum does not tell you how to develop software, it merely dictates moments of communication and ways to transfer information among stakeholders. Scrum is not a software development methodology, you can apply anything you like or are required to as long as you do the planning sessions, stand-ups, demos, maintain the burndown on the wall and assign your roles (SM, PO, team, client). If you want to do or must do ISO, that will just be part of your tasks that you will have to take into account when estimating your stories.

If your software needs to be XYZ compliant, that will just be part of your definition of done. There should not be a conflict, Scrum as such has no authority that enables it to invalidate product requirements. If it feels like that, it is just because some folks are using Scrum as an excuse to have it their way. Which is not uncommon.

Answer 2

Is there a general requirement discovering in SCRUM? Like interviews, surveys with the client and then those stack of requirements are shared with the team in the multiple sprint meetings for the backlog or it's a continue discovering with the team and the stakeholders (users stories in the sprint meetings)

Scrum is silent on the specific methods.

The Product Owner role is responsible for ensuring that the items in the Product Backlog are clearly expressed in a manner that is useful for the Development Team, ensures that the order of Product Backlog items is managed, and ensuring that all stakeholders are clear as to what the team is working on now and will be working on next.

Nothing in the Scrum framework tells the Product Owner how to do these things. The only thing that is the Product Owner is one person. There may be a team of analysts or product managers, but there is a singular person (although I recommend also identifying an alternate) that represents the stakeholders and product vision to the team.

Part of ensuring that the Product Backlog is in a good state is discovering and capturing requirements. But this can be done in any way that is comfortable for both the stakeholders and the product owner.

I have to create a design procedure, which will describe how to approach UI design (mockups, prototype, etc), in SCRUM is not up to the team how they do it? An analyst will follow this procedures and after a view of what the project is going to be share it with the team to begin the implementation, though removing the responsibility of recreating the entire development process for each application without an specific methodology.

Something that may help here is the concept of "Definition of Ready". The Scrum framework defines a "Definition of Done". The Definition of Done helps every team to make sure that the work is fully complete. However, some teams also develop a concept of "Definition of Ready" - the work that needs to be done before the backlog item can be started by the development team.

As far as the team choosing their own work approach, that is a principle of Scrum - the team can inspect the way they are doing work and adapt. However, it is OK to put restrictions on the way the team works, if it comes from outside guidance. It's also possible to perform "process tailoring", even if you have documented processes that correspond to ISO requirements. You just need to fully understand the intention of each ISO requirement and document organizational standards.

---

As an aside, I would recommend looking at Disciplined Agile. One of the process life cycle models implemented in Disciplined Agile is based heavily on Scrum. Other models are based on other agile and lean methodologies. However, unlike Scrum, it does address concerns like governance (ISO standards, CMMI, regulatory requirements) and how to implement agile methods in these environments.

Answer 3

1. Is there a general requirement discovering in SCRUM?

Not expressly, no. To quote Henrik Kneiberg: "The beginning of the project is when you know the least, so why would you plan everything then?"

The whole idea of Scrum is that the needs of the user and the "right" design is emergent. The requirements gather process is ongoing. That being said, it is not uncommon to have a product kick-off or release planning session that lasts maybe a day or two where the whole team talks to users, discusses where a good place to start would be, etc. In my decade of experience, it's worth it to spend that little bit of up-front time, but assuming that everything you identify might be wrong and have to be thrown out should set the bar for exactly how short it should be.

2. I have to create a design procedure, which will describe how to approach UI design (mockups, prototype, etc), in SCRUM is not up to the team how they do it?

Awesome question! Working agreements are completely compatible with Scrum. The best development practices should come from the team, but that team usually has to work with other teams and the company as a whole. You'll need to find the balance. Obviously, if a team wants to build the whole app in Access '97, that's probably a hard no. It doesn't matter if that's what the team wants. On the other hand, try to keep them light. For example, if the whole company is using a particular program for rapid prototyping, include that as the company norm, but be open to teams telling you there's a better option or another choice that doesn't clash (maybe an open source version that saves in the same file formats).

There are two critical tools in Scrum that will help you here: Definition of Ready and Definition of Done. The very short explanation of them is that items must meet the Definition of Ready before the team will take them into a sprint and must meet the Definition of Done before the team can say they are finished. Many places with multiple teams have a common DoR and DoD across all teams and then individual teams can add to them.

Analysts

So, this isn't the main thing, but you mention it and it is something that may trip you up: the "what" or the need that needs to be addressed or problem that needs to be solved is identified and refined by the product owner who talks with the team and the stakeholders as a check on his thinking. Then the team determines how that need will be solved - they create the implementation. If the backlog item is coming to the team with the datasource, UI flow, and graphic elements done, then part of the implementation is happening outside of the Scrum team and the sprint.

Often times when I see this the Analyst and/or designer is doing all that stuff ahead of time and the result is always the same: the analyst and/or designer gets buried. 6 coders just write code so much faster than an analyst can solve complex problems. In this case, solving those problems, designing that interaction is all part of implementation. That designer or analyst is part of the team and should be looped in - that work should be part of the sprint. I know that is a bit outside of your question but I've watched so many teams fall into that trap I wanted to say something.

Answer 4

I think it is worth pointing out that SCRUM is actually more then a set of agile development principles. From my understanding, it actually has a quite well-defined development process (sprints, daily scrums, sprint planning, etc.). So this statement of yours

because in SCRUM the steps are iterative the team decide who process will they use, I'm feeling that it conflicts with having a technical procedure of how the things should be done.

irritates me, because SCRUM has a technical procedure on how to develop software at its core.

Regarding your question

Is there a general requirement discovering in SCRUM?

The role of the product owner is responsible for formulating feature requests, which are further specified (in user stories) during sprint planning meetings.

Unfortunately, I don't know much about ISO 27001, so I can't tell you if it makes sense trying to combine it with SCRUM. However, and I say it again, just because SCRUM is agile does not mean it doesn't define a process. On the contrary, SCRUM clearly defines a process and is quite strict about adhering to it (compared to other agile methods, e.g. Kanban, where you have much more freedom in defining your own adjustments to the process or embedding it into existing processes).

Here you can read more on SCRUM and its process.