Hi Dojo,
I'd like to learn more about the workflows and the transitions that are available in the current implementation of the Collaboration portal: is this currently based just on Scrum and Sprints?
Could it be possible to experiment with Kanban too? Any steer will be helpful.
I have a feeling that Kanban could be helpful where the same squad needs to deal with both project tasks and with any interruptions coming from urgent items in the Maintenance and Support queue: what's the standard workflow in the current deployment? Is Sprint mandatory?
Thank you,
A.
PS: I noticed that in the past, after adding feedback on a "Waiting" item, it could go to "In Progress" - this seems different now, with only one state that can be selected on the customer's side, i.e. "Investigation" - it makes sense, but is it possible to generate/get notifications in the collaboration tool (not via email) when tasks are reassigned? 
With reference to your task-flow, what's the expected state for items that have been scheduled for the current sprint?
No, sprints are not mandatory.. however, in practice almost every squad in Skyline uses sprints because they decided it works best for them. Often in combination with aspects of Kanban. (Scrumban)
Yes, it's more than possible to experiment with Kanban on Project Collaboration. In fact, most of our squads that deal with a lot of unplanned work like the maintenance and support that you mentioned implement a form of Kanban or, like Matthias mentioned, a combination of Scrum and Kanban.
The main ingredients of Kanban are:
- Workflow visualization
- Continuous inspection and improvement of the flow
- PULL principle, both for picking up work and scheduling meetings.
- Work In Progress Limits
You need all four to make Kanban work for you.
For the first and second ingredient the Board view image of Project Collaboration that you added is perfect for this. In one overview you can see the state of each work item and how it will flow from one state to the next. It's also perfect to evaluate the flow. Bottlenecks become apparent when the flow starts to stutter.
The pull principle is something agreed among people, not enforced by Project Collaboration. Nobody assigns work items to you. Instead you only pull, and assign work to yourself. Similar with meetings. There are no fixed meeting dates, you pull, create a meeting whenever the need arises.
Currently it's not possible to show the WIP limit on a status column (yet) but you do see the number of items in a certain state already. As soon as it reaches your agreed limit you stop pulling new work items and instead swarm with the team towards the in progress items to get things done first.
Skyline Communications believes the best results come from self-organizing teams. For many things it doesn't make sense to enforce a procedure on over 300 people who all have different backgrounds, personalities, types of work etc.. What works great for one squad doesn't necessarily works great for another squad. This does indeed make it less transparent to you, our end user, to know when a task is picked up in a sprint. Thanks for helping us become more aware of this!
Some squads use the 'Scheduled' state to inform a task is added to a Sprint, others add it to a 'Sprint Bucket' again others use a specific 'Sprint Label'.
We indeed need to work on making this more transparent, in the mean time, you can simply ask the squad how they work.
It's currently not possible to get notifications in Project Collaboration on task changes.
Agile is my (our) passion as it helps us deliver valuable outcome instead of more traditional companies that only deliver output. I would love to talk more about it with you.. but I don't want this wall of text to grow too large either. Let me know if there is anything else!
“Would you have any more info on setting the priority from a customer point of view?”
In an agile work environment the Product Owner is indeed trusted and empowered by all parties to maximize the value coming out of the squads. She is the one that decides the final priority but does this by taking all variables into account. One of the main variable being the value for the customer. The Product Owner counts on the collaboration with the customer so that she is, or becomes, aware of dependencies or related deadlines.
“Is there any role separation recommended between the Technical Accont Manager, the Project Manager and the Product Owner?”
No. It’s more important to see the Product Owner as someone with a series of accountabilities, not just a job title. Technical Account Managers and Project Managers have a lot of overlapping accountabilities with the Product owner. It could very well be that the Technical Account Manager (job title) fulfills all those accountabilities and is de facto the Product Owner as well or he takes on responsibilities to support whomever is the Product Owner. The Product Owner can very much delegate work to others but she remains accountable for the outcome. This is where the collaboration culture with our customers and inside Skyline is one of our biggest assets.
“And in today’s complex world of many concurrent projects, is it possible to catch-up regurlarly with the technical resources too?”
Absolutely. Agile scope or agile time and material projects implement regular intervals where the developers (could include TAM), key stakeholders (you!) and the Product Owner sit together to be transparent about the work that got done, the obstacles that were discovered, the opportunities uncovered, the changes in the market and even the work that did not get done. The goal being, to update our initial plan and steer it towards the best possible value for our customers with this new information that is uncovered. Instead of sticking to a plan that might have become outdated.
“is there any actual value in re-assigning this without even having a call with the resource that will proceed with the work?”
It depends.. If the new work is very straight forward (it almost never is in our complex environment) then it could makes sense. Or of the Product Owner is aware of what needs to be done and is able to transfer that knowledge to those doing the implementation then this could work too.
Preferably a bridge is built between those doing the work and the end-users who are going to use it day in day out and they can regularly collaborate so that the work that is done will be of value.
Thank for the thourough feedback, Bram
Appreciated – I have to say that were roles are not neat, I’ve seen more margin for failure of the whole Agile model – nevertheless, in the complex technology scenarios we all face nowadays, I think we’d all agree that flexibility is key (and the main reason why we all seem to like Agile).
I’ve had the privilege of working with different squads over time: some with a TAM and a separate PM, some where the PO tends to be more trasversal and so I’ve had to adapt myself to different paces – however I’m happy to say it loud: we all put effort to achieve the delivery – and it’s alwyas been a pleasure to deal with Skyline.
Wishing you a great evening.
Thanks for your answer, Bram – indeed there are limits for the “in progress” items, depending on the resources available and on the task types.
If I know I can have only one protocol fixed per sprint, I don’t ask for two devs working concurrently – though with the amount of fixes in a few legacy protocols that would be helpful 🙂
(stuff I’m using that was validated many years before me)
Knowing there is some flexibility available will help: I’ll work it out with the squads when I get a chance.
I don’t rely too much on rigid structures based on the velocity previously documented in consuming the story points – and I’m not too clear on the number that is assigned at times (300//500 is this just the priority level? The higher the number, the higher the priority?) – So I came here to find more info – not questioning the workflow, just here to learn it 😉
Would you have any more info on setting the priority from a customer point of view?
At present I seem to understand this is only possible for the internal product owner (yet the product owner might be not necessarily briefed about project dependencies and related deadlines).
Besides, when it comes to the adopted AGILE model, is there any role separation recommended between the Technical Accont Manager, the Project Manager and the Product Owner?
I got used to seeing three differnet figures in the past, but if the current model foresees some overlapping, who’s the best point of contact for the customer? And in today’s complex world of many concurrent projects, is it possible to catch-up regurlarly with the technical resources too?
E.g. when a task is passed to customer validation and then it has to be moved back to “in progress” – is there any actual value in re-assigning this without even having a call with the resource that will proceed with the work?
Thanks again for your help,
A.