New team with little to no management of work and lack of processes

I have been working with my current employer for a little over and 2 and half years now and shortly, I'll be moving away from my current team to a new team within the same department.

A few days ago, I sat down with the colleague that use to work within this team to try and get a feel for how this team as a whole works; what processes they have in place for completing projects and such.

From our lengthy chat - the team has no real processes set in place. They do work to a critical path for larger projects, but with smaller adhoc task... it's very sporadic, often with impossible deadlines.

Within the team, there are approximately 15 colleagues, all of which are 1 or 2 pay grades above me - yet with the nature of the business, I'm the person ultimately responsible for completing projects on time.

I've been reading around on project management methodologies; Sigma Six, PRINCE2, Kanban etc and while some of these sites do offer good information, they don't seem to offer 'real world' examples of implementing such methodologies.

Has anyone here had or come across a similar problem, and how they might have tackled it? I don't want to waste peoples time by asking for in-depth solutions, I'd just like some down to Earth, practical advice on how I might approach the situation; to encourage other colleagues, to get them excited about change and frankly, show them how disorganised the system is.

Thanks, Alex

When I moved into my current team we were in this situation, however I had the benefit of coming in as Application Development Manager. You will face challenges without the authority to make decisions, but a lot of what I suggest below doesn't have to be driven from the top down. To be honest, everything I proposed I asked the team, and got their buy in before doing anything. Although Scrum was my solution, I would suggest looking to any popular software development methodology. If you have an open manager, you could become the scrum master if you are the sort of person focused on improvement.

The key is to focus on small improvements in your processes and hold regular, honest, and open, reviews with the team. In my case we implemented scrum through small steps outlined below.

• We began by implementing a kan-ban board and daily stand-ups, to provide visibility of the work that was going on. This gave me an idea of the products we work on, and how much time we were spending on each. From all of this work I created a backlog for each product.

• I then prioritised across ALL of the backlogs, so I effectively had my own backlog spanning projects. I had a tool to filter these by project, so I could work with the appropriate sponsor individually. This laid the foundation for time boxing and committing to work.

• With this list, we introduced the a planning and retrospective meeting. This encapsulating all projects and all team members, so some team members will be working on their own specific tasks, but I started to encourage cross functional working and learning. All stand up discussions are useful, because if someone is talking about something no-one else knows, they had to elaborate enough for us to understand. This aided the learning.

  At this point, the team was lacking cohesion, but we were at least getting things done on all projects, keeping the business happy, and improving quality by adding source control / automated tests. It was a HUGE improvement of the mess that was before, but it was also hard to maintain focus, with no goal other than completing the sprint. We also didn't have demo's as they would not be particularly relevant to any one stakeholder. Because I was both PO and SM, I was relatively gentle on committing the team to too much. It's worth noting we were still delivering a LOT more than prior to my arrival.

• I then tried to slowly shift focus of sprints more to a single product, so we would have a sprint say 60% on one product, but still with other tasks. Eventually, sprints were 90% focused on one task, and stakeholders learnt to 'wait their turn' - after all, we were still achieving a whole lot more than they ever got before. This made Demo's possible for one product at a time.

• Once the sprints were focused, I began to train the stakeholders in Scrum, and turn some of them into Product Owners. This is the stage I am at now, I work with 3 product owners, and still have 2 products I effectively own. Sprints may have 1 or 2 tasks for 'other' projects, but we have a enough focus for a sprint demo with the main stakeholders of the sprint demonstrating only their products new features.

When I moved into my current team we were in this situation, however I had the benefit of coming in as Application Development Manager. You will face challenges without the authority to make decisions, but a lot of what I suggest below doesn't have to be driven from the top down. To be honest, everything I proposed I asked the team, and got their buy in before doing anything. Although Scrum was my solution, I would suggest looking to any popular software development methodology. If you have an open manager, you could become the scrum master if you are the sort of person focused on improvement.

The key is to focus on small improvements in your processes and hold regular, honest, and open, reviews with the team. In my case we implemented scrum through small steps outlined below.

• We began by implementing a kan-ban board and daily stand-ups, to provide visibility of the work that was going on. This gave me an idea of the products we work on, and how much time we were spending on each. From all of this work I created a backlog for each product.

• I then prioritised across ALL of the backlogs, so I effectively had my own backlog spanning projects. I had a tool to filter these by project, so I could work with the appropriate sponsor individually. This laid the foundation for time boxing and committing to work.

• With this list, we introduced the a planning and retrospective meeting. This encapsulating all projects and all team members, so some team members will be working on their own specific tasks, but I started to encourage cross functional working and learning. All stand up discussions are useful, because if someone is talking about something no-one else knows, they had to elaborate enough for us to understand. This aided the learning.

  At this point, the team was lacking cohesion, but we were at least getting things done on all projects, keeping the business happy, and improving quality by adding source control / automated tests. It was a HUGE improvement of the mess that was before, but it was also hard to maintain focus, with no goal other than completing the sprint. We also didn't have demo's as they would not be particularly relevant to any one stakeholder. Because I was both PO and SM, I was relatively gentle on committing the team to too much. It's worth noting we were still delivering a LOT more than prior to my arrival.

• I then tried to slowly shift focus of sprints more to a single product, so we would have a sprint say 60% on one product, but still with other tasks. Eventually, sprints were 90% focused on one task, and stakeholders learnt to 'wait their turn' - after all, we were still achieving a whole lot more than they ever got before. This made Demo's possible for one product at a time.

• Once the sprints were focused, I began to train the stakeholders in Scrum, and turn some of them into Product Owners. This is the stage I am at now, I work with 3 product owners, and still have 2 products I effectively own. Sprints may have 1 or 2 tasks for 'other' projects, but we have a enough focus for a sprint demo with the main stakeholders of the sprint demonstrating only their products new features.