1) Can Agile work in a "team" where 80% of work has to be assigned to 1 or 2 specific people rather than everyone working form the same backlog?
2) Can you recommend any blogs or videos that show what a good retrospective can be like? My only experience is with post-implementation-review style meetings where we make a note of things we could have done better and promise not to repeat the same mistakes in future.
Yep, sure can. That's often the situation with cross-functional teams (e.g., 2 developers, 1 designer, 1 marketer). I recommend putting everyone's work items into the same backlog so it's all collected in one place and you're all looking at a single source of truth. During spring planning, just be mindful of how much capacity you have in each area.
And due to the differences in skill sets, cross-functional teams that bring specialists together have the advantage of having more diverse ways of thinking than teams of people with homogeneous capabilities.
Regarding retrospectives, I don't have a video handy, but check out our page on retros in the Team Playbook: https://www.atlassian.com/team-playbook/plays/retrospective There are instructions for basic retros, as well as a bunch of variations worth experimenting with. The real key, though, is to hold retrospectives regularly so you're holding yourselves accountable to the changes you promise to make and follow-up actions.
There's currently a twitter discussion going on around agile and capacity planning. Some companies find capacity planning to be needed while others say it goes against the whole idea behind agile.
As someone that helps to administer a JIRA instance, I see requests for plugins that help to do capacity planning. When able, we want to provide projects the tools they need to bring success, but don't want to be assisting with them going in the wrong direction.
Would love to hear your take on it.
People say the same thing about roadmaps and a part of me agrees completely. Another part of me has seen the value of a roadmap to help communicate a possible scenario for the delivery of a product to those that otherwise wouldn't understand. The same is likely true in this capacity planning discussion.
I'd encourage you to educate yourself on how capacity planning contradicts the agile values or your agile process and make that risk known to the people excited about the capability. I always share how a roadmap is a guess and remind people that this roadmap will be out of date almost immediately.
A reminder like this puts the risk on the requestor. I hope this helps.
Thanks! As far as educating myself on how capacity planning contradicts the agile values, do you have any specific recommendations for reading material in this area? There's so much out there, I feel like you can find whatever you need to backup any way of thinking, so want to make sure I start on the right path. Thanks again!
As one of Dom's peers who also studies the future of work, I thought I would chime on this interesting question. I've linked to some articles in my answer below. Each is about a 5 min read.
For my part, it isn't that capacity planning in the abstract contradicts agile values. Indeed, one of the principles in the Agile Manifest smells a lot like the idea of capacity planning: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." This implies that you have to match demand to capacity.
On the other hand, traditional capacity planning approaches tend to work against these 2 values from the Agile Manifesto: "Individuals and interactions over processes and tools" and "Responding to change over following a plan". Specifically, traditional capacity planning assumes people have certain specializations and work can be matched to those specializations by managers. The agile community doesn't accept those assumptions. For specialization, most agile coaches would talk about "generalizing specialists". For matching skills to people, most agile coaches would talk about "self-organizing teams". Fundamentally, the mindset behind traditional capacity planning is that management's role is to optimize the utilization of resources. The mindset behind agile is that teamwork is adaptive so capacity isn't a fixed quantity, and that what needs optimizing is the throughput of value in terms of working software.
So how does the agile community reconcile the apparent contradiction between "sustainable pace" and "capacity isn't fixed"? As a start, Scrum changes the units of planning. On the demand side, plan in terms of things that are valuable, like user stories, rather than tasks for a specialized function. On the supply side, plan in terms of teamwork, rather than tasks for specific people. Other agile techniques like Kanban and Mob Programming do away with even those hints of capacity planning, favoring a focus learning about priorities as they go, rather than making big plans upfront.
One of the things about Dom's answer, and your observation about the about the breadth of agile opinions, is to realize how agile, as an adaptive technique, is different from the idea of context-free "best practices". A practice isn't best because everyone in the industry does it. It's best because it works for you and your organization. So I hope the above links help your best practice for capacity planning.
From a Project Management POV, regardless of methodology, you need to have an idea of how long something will take (so you can inform customers, look at budget etc.). This means you need to be able to estimate how long it would take (usually a team of people) to do a given backlog of work. In order to do this, you would need the team's velocity i.e. how much they can do in a given amount of time (usually labelled Sprints and usually 2 weeks) and an estimated backlog of work.
From an estimation POV, the best approach would be to start the work and then give an estimate. Unfortunately most projects do not have this luxury and the PMO will push teams to say how long something will take as early as possible. One of the objectives of grooming sessions is to ensure that the backlog is updated (this includes estimation) and although I prefer regular grooming sessions where we are constantly updating the backlog, sometime we do need to do a 'big-bang' approach and groom all the features for the next release. We all know that the only time an estimate is accurate is when the work ends (so we need to try and balance this process)- however teams do get better at this as the project goes on.
Something similar happens with velocity i.e. at the start of a project, we don't really know what the team can deliver - as the project goes on we get a better idea and plan around this. The problem here is we assume that the same team will remain throughout the project but this is obviously not the case always and this is one of the main reasons for doing capacity planning.
For example, we have done 3 sprints in our project and our velocity is averaging 40 points (team consists of 4 dev, 1 tester and 1 BA) . During the first 3 sprints the team capacity was fairly consistent but in the 4th Sprint, 1 person goes on maternity leave (with no available replacement) and 1 person goes on holiday. In sprint planning we would need to take this into account i.e. rather than committing to 40 points, we would assume 50% capacity for development and plan closer to 20 points (all other things being equal).
Furthermore, in our project plan, if we chose to ignore the new capacity and plan for 40 points (rather than 30 points or less as 1 person is now off the project and cant be replaced), some serious questions would be asked by project stakeholders!
I'm in an organization that does daily stand ups, does two week sprints, does sprint planning (tasks) and does a retrospective, but isn't really agile. We deliver in huge batch sizes, we do almost all the requirements and do all the design before we go into sprint, we don't measure and learn.
How do we move towards true agility and customer-centric delivery when a) the team believes it's agile and b) the business is quite siloed into "commercial" who talk to customers and "development" who build stuff.
You're not alone Callum.
It sounds like you're well on your way to agility! You should pat yourself on the back for holding the ceremonies and structuring your development teams as you do.
This is quite a common dilemma, and I see how your org structure impacts your ability to feel truly agile. My hunch is you'd have the most success trying to involve the commercial teams and leaders deeper in your agile process.
Maybe start by adding a demo meeting and inviting commercial team members. You can demo what your team is working on and have the commercial teams act as the "customer" and give feedback. This may help them see how customer feedback is more useful to your team than the requirements they're passing along.
I wouldn't call the teams out as not agile. Once you achieve the next level of agility the agile way of working will show it's value and hopefully it will be recognized.
What does an agile team mean to you and what is the problem you're trying to solve?
To quote from a previous question:
"Every organisation is different so there will be many ways for this to succeed. One way is to harness the energy and passion your people already have. Find those most passionate about being more agile and give them all the help you can to make them successful. Then you and they can showcase their success to encourage others to join the movement.
For those appearing resistant, maybe they feel forced to change and meeting them where they are will be more effective. Lose the A word and instead use the practices and behaviours that agile encourages to help solve the challenges they have today, Once this starts to work maybe they'll see the benefit; worst case they'll continue to improve and they'll become more agile regardless.
Also, before you talk frameworks (the solution), make sure to ask questions like "why?" and "what for", so you know the real problem you're solving. "
One of the most important ideas to keep in mind is that Agile is really a set of values and principles - you can start with aligning the team here.
The last thing I'll say - also quoted from a question previously:
"For those appearing resistant, maybe they feel forced to change and meeting them where they are will be more effective. Lose the A word and instead use the practices and behaviours that agile encourages to help solve the challenges they have today, Once this starts to work maybe they'll see the benefit; worst case they'll continue to improve and they'll become more agile regardless."
The challenge I have run into w/ Agile is associated with the development of embedded solutions. That is, where a company is developing the hardware system and overlaying the software. Personally, I have not even considered inserting agile into the hardware piece but certainly have on the software deliverables. The challenge invariably comes in when trying to get the QA (system test team) working w/in the same sprint w/o unnecessarily bloating the sprint. What we end up with is a hardware development process (waterfall), a software agile process and then an odd QA process of incremental testing of sprints with a final QA once the last dev sprint is complete. This isn't ideal and I'm always interested in how others in similar product development environments leverage agile practices.
I'll be honest, mate: hardware or component development is not my area of expertise. However, have you looked into a practice called "concurrent engineering"? Again, I'm no expert, but it appears to be a framework for developing physical components in parallel with the software that controls them.
Curious to hear whether other participants in this thread have advice to lend here! #AlwaysLearning
I work at a company that also develops embedded software solutions. We've migrated most development teams to Scrum (with JIRA project boards and BitBucket). The problems associated with relatively longer/delayed hardware, test, and manufacturing time boxes have been tacked a couple different ways with varying success:
This is a work in progress for us and definitely falls under the #AlwaysLearning. I intend to incorporate some of this into a paper for Atlassian Summit '19? :)
Excuse me for my english in advance :)
Tipical situation for companies nowadays:
A company transformation project. They want to transform a traditional process to an Agile methodology. They want to train their people in Agile and use new tools adapted to DevOps (e.g. BitBucket, Github, Jira....)
Inconvenient: They use a waterfall project management to control this project (e.g Prince2).
How would you approach these risks as an Agile coach?
Thank you! And good luck!
Some questions you can ask yourself upfront:
One way we've managed these risks upfront is through using our Health Monitor which checks key team attributes such as shared understanding, managed dependencies, balanced teams, velocity, proof of concept - all of which can get your team started on addressing the risks you've mentioned.
any tips for new build teams (most of them non-technical and a little bit oldschool) that want to start off getting agile? Do you think external support is needed or can a team reach this together?
Looking forward for your answer.
What I find is most important to a team's agile journey, is starting off on the right foot, by setting up a time to introduce everyone to the principles of agile. Even a quick Google search of the "agile manifesto" will help your team grasp what your North Star is as you make the process your own.
I think external support is helpful in cases like this, but that doesn't mean you need to hire a consultant. If there's one person on the team or in the larger organization with previous agile experience, try recruiting them as an informal agile coach as you're transitioning. Alternatively, a person on the team who is inexperienced by highly enthusiastic can serve as the team's "champion" for agile.
The key is keeping momentum and morale high during the transition. As long as you're making steady progress in your agile journey, you're probably doing it right.
Thanks so much for your answer @Dominic Price - makes me feel a lot better about our journey we already started :)
I will take your advice and will look for other people here in the company that want to support our group.
As long as you're making steady progress in your agile journey, you're probably doing it right.
Love it - this will become a printout on my desk!
y question: what do you see comes after Agile? Is there an evolution of it or a new method on the horizon that you guys are watching so you can keep enabling IT teams?
This is a popular question! I'm going to quote the answer I gave in our top-voted question of the day. Let me know if I didn't quite cover what you are asking!
"For Atlassian, we don't think of changing or deleting anything from the original manifesto, rather we are thinking about what principles we'd add as we apply agile in new contexts like Agile at Scale (taking agile into large and traditional organisations that have different levels of complexity) and Business Agility (adapting agile to non-tech teams)."
We're also really excited about the evolution of IT teams and the different methodologies they're adapting.
Hi Dom, hope you are well.
I'm interested in rolling Agile (Scrum/Kanban) out at Scale and would like to know your thoughts on tooling (Portfolio is still a bit rough around the edges...), which framework you prefer (SaFE, DAD, LeSS etc.) and your approach to getting buy-in across the organisation (management, dev teams etc.)?
Thanks very much!
This is certainly a hot topic on this AMA and at the Agile 2018 conference this week!
Tooling: Portfolio has it's pros and cons, but we think it hits the nail on the head where it counts. It allows you to:
For pro tips on how to smooth some of Portfolio's edges ;-) in rolling it out across your organization, you may consider engaging with a certified Atlassian Solution Partner.
Framework: As far as frameworks, to me there's no single one size fits all way of working however scaling agile does need some kind of structure, that includes:-
My mate Tony Grout, who's done this MILLIONS of times helped me write a little pitch formula to get buy-in. It goes a little something likes this,
"Hey upper manager I've heard you're focused on (pick one of more of the following):
There's this thing called being agile, that if done well gets us more value for the same cost or the same value for less cost, helps us manage risk better and we'll also have happier people who produce better quality and save money by us not having to replace them. Can I get 30 minutes in your schedule to tell you how we could start doing this small to see how it can work here?"
Hi @Dominic Price - thanks very much for your reply.
Will have a chat with our local partner at our next AUG - perhaps they can give some examples of Portfolio in action (last time I looked at Portfolio it did have the features you listed but they were not 'complete'). A more visual dependency map (tied to Scrum/Kanban boards) would be most welcome :)
What Scaled Framework does Atlassian use - is it bespoke or do you use one of the industry standards? I have been involved with SaFE and would suggest this works fairly well with organisations already using Scrum.
Thanks for the tips on getting buy-in. I have found that management are happy to use whatever process makes them more money ha..ha.. Seriously most senior management (especially in technology companies) can see the logic behind most of the Agile Principles. When I did my first Waterfall -> Agile project 7 years ago this was definitely a harder sell than it is today - getting metrics from a tool like Jira most certainly helps :)
I'm Bree - a PM on Portfolio. Please feel free to send me an email (email@example.com) if you'd like to chat more about Portfolio. Your local AUG is also a great idea.
Thanks for your feedback on improving our dependency visualisation too :)
If you're trying to suss out where agile will be welcomed vs. where in the org it'll be met with resistance, the Health Monitor comes in handy. If folks resist making changes based on what the Health Monitor reveals (or resist a self-reflective exercise like this in general!), agile is going to be a tough sell. It's not a perfect agile-readiness diagnostic, but it's a decent litmus test.
A good way to smooth the path is to try new ways of working that are fairly similar to the way you're working now. Meet folks where they are, score a win or two, then gently tug them further in your direction. For example, instead of weekly status meetings that take an hour, get them to try daily 10-minute standups. Or if a massive retrospective after a project completes is how your org usually operates, suggest mini-retros every other week throughout the next project. (Instructions for both are in the Team Playbook.)
The Playbook also has loads of other techniques and thought exercises that aren't "agile" per se, but help people see the value in trying different ways of working. The DACI play, which gives structure to group decision-making, and the Goals, Signals and Measures play, which is all about project goals, are good starters. They don't feel like you're following a methodology... it just feels like "working smart".
Hi @Dominic Price,
My question has to do with (missing) trust.
We're a division within the IT department of a large company. Our division is the only one working with Agile practices, the rest is still very much in waterfall mode. I am one of the Scrum Masters/Agile Coaches.
We're now 2 years into our Agile transformation that was initiated by the division's management. The teams are doing great and are getting more and more into the Agile mindset, so the Scrum Masters are obviously doing a good job. It has been very tricky to get management properly on board, though. It seems they didn't understand what Agile entails when they initiated this type of work. Their decision-making is a lot of the time not transparent, they have trouble creating a vision for us, a roadmap for the next few years was created without consulting the teams or at least the Product Owners, they don't follow our processes, etc. There is little trust from management towards the teams (sometimes outspoken), but the teams have lost trust in management also (people don't take decisions seriously anymore). The Agile Coaches have created an Agile strategy for the company that would help us build the trust (through enablement and empowerment), but we don't get commitment for this from the whole management team. We continue to try and make the changes bottom-up, but I'm afraid we can't really do much without the whole management team on board.
Do you have any recommendations/ideas on how we can proceed to make things better?
Thank you in advance for your reply.
Greetings from Vienna
Greetings from San Diego!
Lack of trust and transparency are all too common, in my experience. It's great to hear your teams are gaining momentum in adopting agile, though!
If I were in your shoes, I'd try to figure out the root case of the lack of trust from upper management (the lack of trust is a driver of the opaqueness so start with trust and you'll solve transparency issues too). Start by asking questions and listening and keep digging until you get at the root cause. Once you figure out what's at the root of management's mistrust, reflect it back to a manager you trust in a productive way, focusing on the potential benefits to them and the organization if these root causes are addressed.
That approach may sound generic, but I hope it helps get you a bit closer to uncovering the source of your management team's mistrust. Keep me posted on how it's going!
Some of the pros of using Portfolio for Jira include the ability to:
Some of the cons of using Portfolio for Jira include:
Don't take my word for it though. Check out these blogs to hear straight from customers why they use Portfolio for Jira:
So many serious questions, I feel like I need to throw something fun in to an AMA. What is your favorite way to celebrate team success? How to do you rally the teams, improving moral after a set back? ... and, possibly the most important question, what's your favorite icecream flavor?
Hey Kimberly! I think this is going to be my favorite question to answer
As far as team celebrations go, I don't have a groundbreaking answer for you. My teams tend to want some free food and drink and a bit of time during work hours to consume it together to celebrate success. Sounds pretty basic, but that's what we all like.
Setbacks happen. In fact, the time to start worrying is when there are no bumps in the road because that likely means you're not shipping. My advice is to find the silver lining (sounds corny, I know). What did you learn? How is that going to make life easier moving forward? How much better will your customer's experience be because of the lessons you learned? Trust me, there's an upside to every setback and as leaders we are responsible for helping the team always see the forest among the trees, even when a couple branches fall.
Lastly and most important, my favorite ice cream! Have you been to Sydney? I'm a HUGE fan of Gelato Messina...maybe too big of a fan.
There were a few striking findings from our research.
1: despite lots of writing about technology and impact of tech skills, the challenges of today revolve around human to human, and trust.
2: Whilst we're anticipating impact to jobs and changes to roles, we don't seem to be doing much about it. It's as if we're equipped with the data, but struggling to take action. Should we retrain? What in? Where? Who pays? The disruption to jobs and employment needs more contemplation so that we prevent pain, rather than cure it.
Hello @Dominic Price!
Thanks for this great opportunity. We are using JIRA to plan our products in an agile way since a couple of time and we have some questions that occured during our JIRA Usage.
Our questions refer to the following facts:
Therefore, we adapted the classical SCRUM process and defined the following work process:
We have one JIRA project that is representing a functional team with members that are functionally responsible for different sub-projects. We use "components" to define the different sub-projects and assign a component leader as responsible person. The component leader has the role of a product owner, that is responsible to define and maintain a product backlog for that component. Therefore, we created seperate boards for every component, which are filtered by the component's name. After that, each product owner defines elements of his component backlog that he wants to be handled in the next sprint. This way a "selected backlog" is created that is a collection of prefered issues of every component. This is the input for the sprint planning, where the team decides which issues may be realized in the sprint or not, so that the final sprint backlog is created.
We believe that in an classical, large enterprise this problematics are very common.
We would appreciate if you could give us some suggestions.
Thanks in advance, looking forward to your answers.
I've had a look at Holacracy website a few times, and I'm fascinated by some of the concepts, but I'll admit, I've never truly tried to follow it.
Based on the #retroonagile we ran in our booth this week, there is no doubt room for growth with Agile, but also an overwhelming amount of happy, devoted Agile adopters.
@Alexey Matveev: Probably best to say that Holacracy and Agile are equally similar as they are exceptionally different.... and same old answer, that fits all approaches to management of organisations, projects, process, change, etc.: "Choose the one that best suits your organisation" ;o)
@Kat : You're not wrong there, although a company can still just pick up the book and be Holocratic without the getting accreditation. Not easy though: check out on any streaming service how Zappos has achieved Holacracy. Loads of videos on it.
Here's both in a nutshell from the almighty Wikipedia - I've taken the term Agile to mean 'Agile Software development' (i.e. the birth place of agile):
Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
Holacracy is a method of decentralized management and organizational governance trademarked by HolacracyOne, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy. Holacracy has been adopted by for-profit and non-profit organizations in several countries
When people talk about Agile, mostly they refer to Scrum which is the most popular methodology. Couple of questions from my side related to that..
Is Agile (Scrum) actually a good option for distributed teams? Comparing both, a team working in the same room and distributed. Would both have the same velocity? Would it change if they would switch sides?
If you have many remote teams and you want to make a switch inside a team... How does it work if you switch individuals across different teams that are working remotely? Are they adopting slower and being a bottle neck instead giving more value to the team?
What about timezones and meetings across the globe where you cannot have sometimes even 1 hour to go through the sprint planning or retrospective without rush? Is this effective Agile?
After few sprints and deliveries team notice that they are starting to receive more and more bugs. Suddenly they realize that do not have time to deliver something new to customer (spending time only on bugs). Very often then they want to estimate those bugs like stories. Is this goo approach even estimate is called a "Story Point" not "Bug Point" or something similar.. Do we even can estimate a bug (like stories) if this requires initial troubleshooting and might be hard to put it next to new features.. Maybe there should be a dedicated team that only resolves bugs using Kanban not Scrum and bugs should not land in backlog?
Do you feel that when using Scrum people do not take much attention to documenting things? Even Agile manifesto says: "Working Software over comprehensive documentation". Not having good documentation not always work if the project is bigger and people are switching across teams.. and later resolves bugs..
Thanks for replying! :)
According to a study of 10,000 teams performed by Larry Maccherone and his team at Rally, distributed teams are actually higher performing than co-located teams. Larry's study also shows that the benefit of being distributed is reversed when teammates are more than three timezones away....which is unnerving for me given my team is spread across Minneapolis, San Francisco and Sydney, but the reality is, that's the norm these days so we are forced to find ways to collaborate better and continuously improve our practices.
Adopting a tool that allows every team member to see exactly where work is in the workflow is a critical piece to making my distributed team function (we use a combination of Confluence, Jira and Trello). There are probably many tools that can do the job, but since I know most about Jira.... it allows teams to slice and dice work into the workflow stages that make sense for the team, which means everyone is on the same page and held accountable for their contribution to the project. Commenting and feedback can be done in real-time, in Jira, so potential bottlenecks or blockers don't have to wait until a formal meeting. It also keeps sprint planning and reviews with the team very focused (because my whole team has shiny object syndrome).
Check out the rest of Larry and team's study for more insights into comparing co-located and distributed teams velocity, quality and productivity.
What would be the real motivation factors for a team to keep agile "going"? Or how to avoid bumpy rides in an agile road.
I have seen some frustrated teams that wishes they got the real benefits every minute they spend within the agile environment.
I think the frustration is sometimes that you're following the rituals, but not seeing the results. In my experience, that is often caused by not realising the real outcome of the ritual. EG: I've seen teams religiously complete retro's, but get frustrated, that is because the same things are coming up every time. They aren't following through or management isn't helping to remove systemic blockers.
I also think many teams and organisation can do better at storytelling about what works and what doesn't, and being open and honest about the challenges they're facing. Also have customers and business people come in and share stories about how the software your teams are creating are helping improve the lives of people. Sadly agile teams can, over time get disconnected from the value they're creating, and working down a backlog can just feel like you're a backlog item processing machine.
When you read about Netflix and their culture deck (Patty McCord book "Powerful"), they were always very honest with the challenges the company was facing. No sugar coating.
There will be bumpy rides, so just make them less of a surprise.
Yes! Tools can absolutely get in the way! I like to say that "a fool with a tool is still a fool... but now they're able to be foolish much more efficiently"
Look: tools aren't worth a damn unless they're supporting effective collaboration practices. If your planning and prioritization practices are crap, and you buy Jira, your practices will still be crap. The only difference is that now people will blame the tool. Which really sets you back because you're masking the true root of the problem.
So get the practices and people right first. Only then should you layer a tool on top of them.
I think if you google most popular methodologies, you get that.
In truth, I think it's time for us to reframe Agile, and the variants of Agile, by going back and falling in LOVE with the problem we're solving.
We also need to stop looking for other teams alleged "best practice" and plugging it into our organisations, without realising that they other company is in a wholly difference environment to us.
Hi @Dominic Price,
As a member of the agile team, we use a variety of visual kanbans.
In addition to Jira's Scrum Board/Kanban, the physical whiteboard is also the way we use it.
I think whiteboards are more conducive to team focus issues and faster writing in daily standing meetings.
I want to know if everyone will use it like this? In what scenario will Jira's board be used, and when will other categories of boards be used?
As a start, whiteboards are a great way of bringing a scrum or kanban practice into your building. When you start standing around a whiteboard, you end up having conversations about how your team is working that you probably never had before.
Jira's Scrum and Kanban boards are great for more mature teams with agreed upon processes.
We also recently created an alternate board type in our Cloud version of Jira (what we're calling the agility board for now) for teams or projects that aren't as clear about their processes. It's entirely configurable, so you can add/remove/customize your workflow stages, add or remove sprints or a backlog, etc. Basically it lets you define the workflow that works best for your team and the project at hand. I think this board would be appropriate choice for projects that aren't clearly Scrum or Kanban.
Hi @Dominic Price !
What will be next after Agile process implementing? How to management will measure scaling teams/company?
I mean SAFe or LeSS for the IT - service, prduct deevelopment, how to understand proactively when we need to review our process.
There's really no "done" in implementing agile processes as you should be continuously improving. Two things we are thinking about beyond agile for teams is agile for non-tech teams and agile at scale (across larger and increasingly complex organizations). Watch this space for more of our thoughts on what's next in those two spaces!
As far as proactively reviewing team processes, I am a huge advocate (as you can see in many of my other answers) of getting in the habit of doing a monthly Health Monitor with your team. It's a good way to make sure you are doing regularly thinking about not just what you are building but how you are working.
My organization is stuck in what I phrase as an "Agile-Fall" world. We've adopted methodologies depending on the team working the project which has allowed some flexibility; however, in doing so it has prevented cross-functional teams from being consist.
As an advocate of agile, how can one effectively outline and articulate the benefits of agile even for teams (e.g., Infrastructure) who claim they will forever be waterfall?
In order to be considered agile what are the basic requirements?
What is the greatest difference between DevOp and Agile teams?
Does agile work for projects outside of software development (e.g., business requests)?
If agile did not exist what methodology would you use?
What is the best practice or advise for teams that are reluctant to maintaining a backlog?
Hey LeKisha lots of good questions in here.
As an advocate of agile, how can one effectively outline and articulate the benefits of agile even for teams (e.g., Infrastructure) who claim they will forever be waterfall? I'm going to tap into my years as a management consultant to answer this question, the key to convincing someone of the benefits of agile is to first understand what's important to them and then to meet them where they are. Don't try to go full Kanban on day one, figure out how to apply the agile principles to solve the team's most pressing pain points and go from there. Frameworks and methodologies aside, the key is whether teams are successfully delivering customer value.
In order to be considered agile what are the basic requirements? The most basic requirement is the mindset. Values such as collaboration, learning, growth, customer centricity should be at the heart of the practices a team adopts.
What is the greatest difference between DevOp and Agile teams? A simple way of describing is this is that DevOps is about shipping the software faster with lower bugs and agile is about shipping the right thing using fast feedback loops, relying on DevOps for the fast feedback loop to be possible in most cases.
Does agile work for projects outside of software development (e.g., business requests)? Sure, agile is an approach for dealing with uncertainty by continually inspecting and adapting your outcome and your processes to make them better. I used agile to remodel my apartment with the contractor while I was in Seattle and they were in London, UK. We used Scrum as the approach and used video conferencing to overcome the distance. Daily Scrum every morning my time and building the Sprint backlog weekly. In the Sprint demo at the end of the week the team would walk around with the webcam demonstrating the completed work. We then retro'd on what we could do better next week. I didn't use the Scrum words with the contractor, he liked the approach - well he said he liked the approach :-)
If agile did not exist what methodology would you use? It would look like agile .
What is the best practice or advise for teams that are reluctant to maintaining a backlog? Perhaps start with seeking to understand what's blocking them from maintaining the backlog, whether it's a principle or practice challenge. If it's principle help them understand the benefits (that are aligned with what they value) and if it's practice figure out how to communicate what efficiencies will be gained, even if it means a temporary slowdown.
We have heard this feedback a lot, and is a reason we built a new project type in our Cloud offering.
Scrum and Kanban are great for teams with mature processes and clearly defined roles and responsibilities. But we also realize that not all teams have that all figured out yet.
So we recently created a more flexible, yet powerful, board type to suit the needs of teams who want to create and customize their own unique workflow. The board is entirely configurable, down to things like naming the columns, reordering them, or removing them entirely. If and when you're ready, sprints and backlogs can be turned on in a simple click. The goal here is to let the teams define the workflow that suits their needs best.
I do love day dreaming about the future workplace and what it might be like. I don't really have any predictions, but there are some trends that fascinate me.
Most of us are probably pretty familiar with traditional Retrospectives. But we’ve got another variation for you to try – and we think you’ll really like it! It’ll not only help you make room for doi...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events