Showing posts with label Self Organizing Team. Show all posts
Showing posts with label Self Organizing Team. Show all posts
Saturday, 6 October 2018
Wednesday, 21 March 2018
Distributed Agile Leadership
Continuing the Auspicious Agile Leadership Series - looking at Distributed Agile Leadership. This video blog goes along with the recent release of our distributed Agile team's InfoQ article on Distributed Agile Leadership, and the release of our mini-book on InfoQ. Look out for our full ebook which will be released soon.
InfoQ article and Mini-book links are included below:
InfoQ Distributed Agile Leadership Article
InfoQ Distributed Agile Mini-Book (does not include Agile Leadership section)
If You enjoy Auspicious Agile you can support us on Patreon – Controbutions of $5 or more will get early access to our full "Distributed Agile Framework" ebook when it is available - https://www.patreon.com/AuspiciousAgile
Also support Auspicious Agile by shopping on Amazon using the link below!
https://www.amazon.com/?tag=auspiagile-20
Ledger Nano S Bitcoin Wallet (Get it on Amazon)
Trezor Bitcoin Wallet (Get it on Amazon)
InfoQ article and Mini-book links are included below:
InfoQ Distributed Agile Leadership Article
InfoQ Distributed Agile Mini-Book (does not include Agile Leadership section)
If You enjoy Auspicious Agile you can support us on Patreon – Controbutions of $5 or more will get early access to our full "Distributed Agile Framework" ebook when it is available - https://www.patreon.com/AuspiciousAgile
Also support Auspicious Agile by shopping on Amazon using the link below!
https://www.amazon.com/?tag=auspiagile-20
Ledger Nano S Bitcoin Wallet (Get it on Amazon)Trezor Bitcoin Wallet (Get it on Amazon)
Sunday, 23 October 2016
The Culture Change of DevOps (Video Blog)
This week's Auspicious Agile Video Blog takes a look at the culture change of DevOps. DevOps requires more than just adopting tools, it also requires changes in culture and the way we work. Here we look at several culture aspects in DevOps to consider.
Here are some of the links and resources mentioned in the video blog:
- Xebia Labs periodic table of DevOps - https://xebialabs.com/periodic-table-of-devops-tools/
- Phoenix Project by Gene Kim - http://www.realgenekim.me/
- Dan Pink Drive - https://www.youtube.com/watch?v=u6XAPnuFjJc
- Auspicious Agile first blog on culture change of DevOps - https://auspiciousagile.com/2016/02/20/the-culture-change-of-devops-and-your-career/
- Mirco Herring, DevOps Leadership Culture - https://notafactoryanymore.com/tag/devops-culture/
Wednesday, 30 July 2014
The Best Agile Manager I Ever Worked For
As we continue to explore Agile leadership, today I want to talk about the best Agile Manager that I ever worked for. It was several years ago, and I was working as part of a group that did custom software development projects for customers. I started work on a new project that I had helped to kick-off several months before. The project was for a US Government customer and the team manager was Jack (not his real name).
The team was made up of a business analyst, six or seven developers, and a development lead. The team had recently started to use Agile methods, and was definitely in the midst of transitioning. Jack was responsible for delivering the project for the US Government customer. I joined the team in a senior developer and architect role. The team needed to to develop a service integration capability quickly in order to fulfil the US Government requirements for the project.
What I liked about Jack's leadership style was that he empowered his team, he set vision for the team and looked to the members of the team to figure out how to get the job done. Jack certainly fit the mould of a servant leader consistent with Agile principles. This was a stark contrast, considering I had recently worked on a team with what I would consider to be the worst Agile Manager I had ever worked for (see archived blog post for that story), we will call him Bob.
To compare and contrast the other Manager that I had worked for previously was authoritarian. No opinion was tolerated but his own. His style of leadership was to create fear in the team. Jack by contrast set vision and inspired the team to achieve its goals. He did not use fear as a management tool, but rather he would seek to encourage the team, and to constantly find ways to remove roadblocks and impediments.
Jack was also trusted by the team. When Jack asked a question or inquired into something, there was little question in your mind that he had good intentions and was looking to benefit you and the team. By contrast when Bob (the fear based authoritarian manager) asked you a question, your heart would start to beat faster because you knew he was likely not asking for any good reason. Rather he was generally seeking a way to accuse or belittle the team members, and most of his questions followed that pattern.
There was a prevailing good morale on Jack's team. Even when we were up against a deadline or a challenge the team still worked together well and was positive. Whenever we faced a challenge, the team was always engaged, focused and would "Fight On!" (the slogan selected by one of the team's developers). By contrast on Bob's team everyone was just waiting for an opportunity to get off his team, and hoped they didn't make any mistakes that would get them in trouble.
Now notice that I did not focus here on how Jack did stand-ups, or how the team did retrospectives. The team was learning, and did a decent job of putting these Agile rituals in place. What made Jack a great Agile leader was not that he was able to follow Agile rituals. What made Jack a great Agile leader was that he followed Agile principles in his leadership and the way that he treated his team. This included respect for the team, openness, focus, simplicity, and trust.
Looking at the picture of Jack and contrasting with Bob who I described several blog posts ago, who would you rather work with as your manager? When you think about who you would prefer, also think of the reasons why, is it based on following Agile practices, or is it based on the underlying Agile principles? Food for thought...
Until next time, stay Agile,
John.
The team was made up of a business analyst, six or seven developers, and a development lead. The team had recently started to use Agile methods, and was definitely in the midst of transitioning. Jack was responsible for delivering the project for the US Government customer. I joined the team in a senior developer and architect role. The team needed to to develop a service integration capability quickly in order to fulfil the US Government requirements for the project.
What I liked about Jack's leadership style was that he empowered his team, he set vision for the team and looked to the members of the team to figure out how to get the job done. Jack certainly fit the mould of a servant leader consistent with Agile principles. This was a stark contrast, considering I had recently worked on a team with what I would consider to be the worst Agile Manager I had ever worked for (see archived blog post for that story), we will call him Bob.
To compare and contrast the other Manager that I had worked for previously was authoritarian. No opinion was tolerated but his own. His style of leadership was to create fear in the team. Jack by contrast set vision and inspired the team to achieve its goals. He did not use fear as a management tool, but rather he would seek to encourage the team, and to constantly find ways to remove roadblocks and impediments.
Jack was also trusted by the team. When Jack asked a question or inquired into something, there was little question in your mind that he had good intentions and was looking to benefit you and the team. By contrast when Bob (the fear based authoritarian manager) asked you a question, your heart would start to beat faster because you knew he was likely not asking for any good reason. Rather he was generally seeking a way to accuse or belittle the team members, and most of his questions followed that pattern.
There was a prevailing good morale on Jack's team. Even when we were up against a deadline or a challenge the team still worked together well and was positive. Whenever we faced a challenge, the team was always engaged, focused and would "Fight On!" (the slogan selected by one of the team's developers). By contrast on Bob's team everyone was just waiting for an opportunity to get off his team, and hoped they didn't make any mistakes that would get them in trouble.
Now notice that I did not focus here on how Jack did stand-ups, or how the team did retrospectives. The team was learning, and did a decent job of putting these Agile rituals in place. What made Jack a great Agile leader was not that he was able to follow Agile rituals. What made Jack a great Agile leader was that he followed Agile principles in his leadership and the way that he treated his team. This included respect for the team, openness, focus, simplicity, and trust.
Looking at the picture of Jack and contrasting with Bob who I described several blog posts ago, who would you rather work with as your manager? When you think about who you would prefer, also think of the reasons why, is it based on following Agile practices, or is it based on the underlying Agile principles? Food for thought...
Until next time, stay Agile,
John.
Saturday, 12 July 2014
Is making money the most important thing for an Agile team?
In the last few weeks in meetings in Malaysia and Singapore the topic of whether making money should be top priority for an Agile Team has come up. For purposes of this discussion we will assume that the Agile team is a part of a larger business or organisation, and is not a stand-alone group. So the larger question would be is making money the most important thing for the business or organisation that the Agile team is a part of.
From an Agile perspective we always focus on delivering value for the business or organisation (http://agilemanifesto.org/principles.html). So let's define value. In most cases if the business is a for-profit company or organisation value takes the form of producing better bottom line results. This could be reducing costs, increasing revenue, increasing customer satisfaction, or improving employee morale in the company. These may also apply to a non-profit organisation that seeks to break even, but not necessarily make a profit. There are of course other areas where a team could deliver value, such as increasing market share, or improving company image.
So in order for an Agile team to deliver value to the business and organisation one of these areas should be improved by the team's work. Now the question is which of these or other ways of delivering value to the organisation is most important. Let's start with reducing costs, and proceed through the others. If the team develops a productivity improvement that reduces costs for the company, then the organisation should be more profitable, and this will show as better bottom line results (i.e. company keeps more of the revenue it generates). So reducing costs is directly related to making money.
Next we have increasing revenue. This also is directly making more money for the company. So work by the Agile team that increases revenue is also focused on the organisation making more money. Increasing customer satisfaction means that likely more customers will use the organisations product or service. Satisfied customers are happy spending their money on the company's products and services. So customer satisfaction, while initially measured potentially by a survey or some other measure, in the end also results in the company making more money.
Now let's look at improving employee morale. It can be said that if employee morale improves that happy employees will create better products and take pride and ownership in the work that they produce. Now better products, and happy employees likely will lead to the company making more money, but it can be argued that improved employee morale does not always lead to the company making more money. Happy employees also tend to be more likely to stay with the company, and attract others to the company. This saves money for the company in its recruiting and related costs of finding and retaining talented people. However, let's say for now that employee morale is not always measurable in bottom line results.
Increased market share, likely will result directly in the company making more money from more people buying its products or services. An Agile team contributes to increased market share by creating great features and services that are valuable in the market place. So again increased market share (in a well run company) should lead to the company making more money. Lastly I mentioned improving company image. This could take the form of better brand position in the market, or better brand recognition. When more people know your company (hopefully for the right reasons) the company is again likely to make more money, through more people choosing to do business with the organisation.
Now, this is certainly not an exhaustive list of value producing activities in a company or organisation, but does touch on some of the most important for a for-profit company. In addition there are non-profits, but most of these still apply, as a non-profit generally needs to break even to continue operating (this may take the form of attracting more money donations, which again would be value producing for the non-profit - take Wikipedia as an example).
So of our entire list just about every value producing activity for the Agile team ends up with the company or organisation making money. Arguably we could say employee morale is not directly measurable in dollars and cents, but ties to money outcomes in many ways as well. So if an Agile team is seeking to produce value for the organisation that it belongs to, it seems very likely that the value produced will have a financial or money measure. This would point to making money for the organisation being the most important activity for an Agile team.
I would add to this one final point. Even if an Agile team does not choose to focus on producing money for its organisation, the organisation will only be able to continue to operate as long as there are finances (money) to support the business as a going concern. So if an Agile team does not support the monetary success of its organisation, the team may not be able to continue as a team if the organisation it belongs to is not profitable or at least able to break-even (in the case of a non-profit).
Until next time, keep thinking about Agility,
John.
From an Agile perspective we always focus on delivering value for the business or organisation (http://agilemanifesto.org/principles.html). So let's define value. In most cases if the business is a for-profit company or organisation value takes the form of producing better bottom line results. This could be reducing costs, increasing revenue, increasing customer satisfaction, or improving employee morale in the company. These may also apply to a non-profit organisation that seeks to break even, but not necessarily make a profit. There are of course other areas where a team could deliver value, such as increasing market share, or improving company image.
So in order for an Agile team to deliver value to the business and organisation one of these areas should be improved by the team's work. Now the question is which of these or other ways of delivering value to the organisation is most important. Let's start with reducing costs, and proceed through the others. If the team develops a productivity improvement that reduces costs for the company, then the organisation should be more profitable, and this will show as better bottom line results (i.e. company keeps more of the revenue it generates). So reducing costs is directly related to making money.
Next we have increasing revenue. This also is directly making more money for the company. So work by the Agile team that increases revenue is also focused on the organisation making more money. Increasing customer satisfaction means that likely more customers will use the organisations product or service. Satisfied customers are happy spending their money on the company's products and services. So customer satisfaction, while initially measured potentially by a survey or some other measure, in the end also results in the company making more money.
Now let's look at improving employee morale. It can be said that if employee morale improves that happy employees will create better products and take pride and ownership in the work that they produce. Now better products, and happy employees likely will lead to the company making more money, but it can be argued that improved employee morale does not always lead to the company making more money. Happy employees also tend to be more likely to stay with the company, and attract others to the company. This saves money for the company in its recruiting and related costs of finding and retaining talented people. However, let's say for now that employee morale is not always measurable in bottom line results.
Increased market share, likely will result directly in the company making more money from more people buying its products or services. An Agile team contributes to increased market share by creating great features and services that are valuable in the market place. So again increased market share (in a well run company) should lead to the company making more money. Lastly I mentioned improving company image. This could take the form of better brand position in the market, or better brand recognition. When more people know your company (hopefully for the right reasons) the company is again likely to make more money, through more people choosing to do business with the organisation.
Now, this is certainly not an exhaustive list of value producing activities in a company or organisation, but does touch on some of the most important for a for-profit company. In addition there are non-profits, but most of these still apply, as a non-profit generally needs to break even to continue operating (this may take the form of attracting more money donations, which again would be value producing for the non-profit - take Wikipedia as an example).
So of our entire list just about every value producing activity for the Agile team ends up with the company or organisation making money. Arguably we could say employee morale is not directly measurable in dollars and cents, but ties to money outcomes in many ways as well. So if an Agile team is seeking to produce value for the organisation that it belongs to, it seems very likely that the value produced will have a financial or money measure. This would point to making money for the organisation being the most important activity for an Agile team.
I would add to this one final point. Even if an Agile team does not choose to focus on producing money for its organisation, the organisation will only be able to continue to operate as long as there are finances (money) to support the business as a going concern. So if an Agile team does not support the monetary success of its organisation, the team may not be able to continue as a team if the organisation it belongs to is not profitable or at least able to break-even (in the case of a non-profit).
Until next time, keep thinking about Agility,
John.
Subscribe to:
Posts (Atom)