It was a great pleasure to have attended Agile 2015. The sessions were mostly good, but my favourite part of the conference was "Open Jam" space. It was an open space where folks could propose topics and a small group of 4 to 6 people would discuss the subject around a small round table. The "Open Jam"s were more interactive than the sessions and was a great way to get to know folks and talk about real problems facing teams. I actually ended up attending more "Open Jam"s than sessions.
There was one open jam on Wednesday that stood out for me, but not in a good way. The session was proposed by a practitioner who was looking for games or a new way of doing retrospectives so that she could use to engage the one or two developers that think of retrospectives as a waste of time. As we learned later on in the conversation, she was a PA on the team and there were a couple of developers on her team that would rather be at their desks coding than be in a retrospective.
The collection at the table was illustrious. There were two experienced developers who just happened to be there and were looking for a space to pair program, they left pretty soon. The other two folks at the table were stalwarts of the agile development community. One of them is an original signatory of the Agile manifesto and the other's name shows up on the signatories page online (http://www.agilemanifesto.org/authors.html). In hindsight, I should have been more excited to see the two agile luminaries in action, but I was brought there by the topic of the open jam, and that was the focus for the moment.
The session was a little off right from the beginning. The PA looking for coaching had barely finished framing the problem that she had before she was hit with a series of questions, none, directly about the problem she was describing. "How involved is your product owner?", "What is the size of your team?", "How often do you release software?" were examples of the questions asked. While these might have indirect bearing on the issue at hand, the connection between the issue and the questions was never made clear to the practitioner who was being asked the questions. On the other hand, each of the answers she gave were treated as problems by themselves. I took direct issue with the experts pointing out that the team size of 20 people was an issue. We will come back to that in a bit.
Taking issue with the declaration that the team size was the biggest problem gave me the opportunity to interject and have two minutes to talk to her about the actual problem she was bringing up and we(her and I) figured out that the developers motivation, for example shipping code, needed to be talked about at the retrospective. If the retrospective was centered around things that are in the way of us shipping software and getting work done, the developer could be a lot more engaged and the retrospectives would be very beneficial for the team. At that point one of the experts agreed and started talking along the same lines. It was good to see some agreement around the table and it seemed we were making some progress.
Somehow the conversation came back to team size. I had mentioned that I have a 34 person team that delivers software on time and successfully exhibits the right team behaviours. This seemed highly extraordinary to the experts. They were a little taken aback that their 7 +/- 2 team size theory was being challenged. The lady asking the question had to leave to attend a session and I hope she got enough answers to make headway with the issue she is facing. Meanwhile, the rest of the table continued the team size discussion. I was asked how big should a team be if you were asked to build a team. Apparently my response of "it depends on the project or product to be built" was a "bullshit answer" according to the expert who signed the agile manifesto. I wonder if the same expert would choose a tech stack without knowing what product to build (I did not have the quickness of mind to ask this on the spot). I did explain to him that it was an inadequate question, as the composition of a team without a purpose is irrelevant and we need to define what the team is doing before deciding it's composition.
There was an interesting twist though. After I mentioned that at my company the average team size is 15 to 20 team members and we have a thriving and successful agile culture, they noticed that I worked at Ultimate Software and their demeanour seemed to change. They had both consulted at Ultimate about 8 years back and heaped praise on the culture at the company. They were gracious in their praise and conceded that the team sizes could work in that culture. The name of the CTO of my company was dropped in the process as well. They remembered how we used to hand out "Purple Cow" toys. These used to represent standing out in a crowd and being remarkable. At the end of the conversation, I took my leave and thanked the folks for the fun conversation.
That was the story(at least from my perspective) of the session. I had some obvious issues with it. The biggest issue was the body language and demeanor of the stalwarts towards the person looking for advice. One of them leaned back in an "I know better than you" position in his chair and spoke in what sounded to me like a condescending voice while asking follow up questions, and at times even asking them before person had answered the initial question. He also took obvious pleasure in landing zingers like "so you don't have a product owner" when they were told the product owner is not always present for the team. The other stalwart, the more famous one, from the agile manifesto, on the other hand, had the same condescending demeanor and was playing a game on his tablet throughout the conversation. This same expert did not even have the decency to look up from the game as he was asking or answering questions to the folks around the table. It was a bit shocking to say the least. He showed a lot more interest in the game than anything else for the course of the conversation.
It was just one instance, but if this is how these "Grand Old Men" of agile treat people and talk to individuals they should stay miles away from coaching people at close quarters. They have done great things in the past and have written books and papers that I and many of us have read. They have made practices that have changed the industry commonplace. They are great minds who have changed software development to a great extent, but in lieu of being able to treat folks who come to you with decency, they should probably stop coaching/consulting people and teams.
I had a great time at Agile 2015, met some great people, acquired some great ideas. The sessions, both scheduled talks and most open jams were great. There were some very empathetic coaches and leaders who presented great new ways of helping, inspiring and bringing teams together. It was one bad experience with a couple of grand old men of agile that was the "Purple Cow", but not in a good way. I hope I just caught them on a bad day at a bad time. If that was the case though, they should probably have stayed away from "trying" to provide help. Maybe they should leave that to the other empathetic, bright coaches who are passionate about helping teams and people achieve the best results without coming across as condescending or disinterested. I have to say I met quite a few of those at the conference this year.
There was one open jam on Wednesday that stood out for me, but not in a good way. The session was proposed by a practitioner who was looking for games or a new way of doing retrospectives so that she could use to engage the one or two developers that think of retrospectives as a waste of time. As we learned later on in the conversation, she was a PA on the team and there were a couple of developers on her team that would rather be at their desks coding than be in a retrospective.
The collection at the table was illustrious. There were two experienced developers who just happened to be there and were looking for a space to pair program, they left pretty soon. The other two folks at the table were stalwarts of the agile development community. One of them is an original signatory of the Agile manifesto and the other's name shows up on the signatories page online (http://www.agilemanifesto.org/authors.html). In hindsight, I should have been more excited to see the two agile luminaries in action, but I was brought there by the topic of the open jam, and that was the focus for the moment.
The session was a little off right from the beginning. The PA looking for coaching had barely finished framing the problem that she had before she was hit with a series of questions, none, directly about the problem she was describing. "How involved is your product owner?", "What is the size of your team?", "How often do you release software?" were examples of the questions asked. While these might have indirect bearing on the issue at hand, the connection between the issue and the questions was never made clear to the practitioner who was being asked the questions. On the other hand, each of the answers she gave were treated as problems by themselves. I took direct issue with the experts pointing out that the team size of 20 people was an issue. We will come back to that in a bit.
Taking issue with the declaration that the team size was the biggest problem gave me the opportunity to interject and have two minutes to talk to her about the actual problem she was bringing up and we(her and I) figured out that the developers motivation, for example shipping code, needed to be talked about at the retrospective. If the retrospective was centered around things that are in the way of us shipping software and getting work done, the developer could be a lot more engaged and the retrospectives would be very beneficial for the team. At that point one of the experts agreed and started talking along the same lines. It was good to see some agreement around the table and it seemed we were making some progress.
Somehow the conversation came back to team size. I had mentioned that I have a 34 person team that delivers software on time and successfully exhibits the right team behaviours. This seemed highly extraordinary to the experts. They were a little taken aback that their 7 +/- 2 team size theory was being challenged. The lady asking the question had to leave to attend a session and I hope she got enough answers to make headway with the issue she is facing. Meanwhile, the rest of the table continued the team size discussion. I was asked how big should a team be if you were asked to build a team. Apparently my response of "it depends on the project or product to be built" was a "bullshit answer" according to the expert who signed the agile manifesto. I wonder if the same expert would choose a tech stack without knowing what product to build (I did not have the quickness of mind to ask this on the spot). I did explain to him that it was an inadequate question, as the composition of a team without a purpose is irrelevant and we need to define what the team is doing before deciding it's composition.
There was an interesting twist though. After I mentioned that at my company the average team size is 15 to 20 team members and we have a thriving and successful agile culture, they noticed that I worked at Ultimate Software and their demeanour seemed to change. They had both consulted at Ultimate about 8 years back and heaped praise on the culture at the company. They were gracious in their praise and conceded that the team sizes could work in that culture. The name of the CTO of my company was dropped in the process as well. They remembered how we used to hand out "Purple Cow" toys. These used to represent standing out in a crowd and being remarkable. At the end of the conversation, I took my leave and thanked the folks for the fun conversation.
That was the story(at least from my perspective) of the session. I had some obvious issues with it. The biggest issue was the body language and demeanor of the stalwarts towards the person looking for advice. One of them leaned back in an "I know better than you" position in his chair and spoke in what sounded to me like a condescending voice while asking follow up questions, and at times even asking them before person had answered the initial question. He also took obvious pleasure in landing zingers like "so you don't have a product owner" when they were told the product owner is not always present for the team. The other stalwart, the more famous one, from the agile manifesto, on the other hand, had the same condescending demeanor and was playing a game on his tablet throughout the conversation. This same expert did not even have the decency to look up from the game as he was asking or answering questions to the folks around the table. It was a bit shocking to say the least. He showed a lot more interest in the game than anything else for the course of the conversation.
It was just one instance, but if this is how these "Grand Old Men" of agile treat people and talk to individuals they should stay miles away from coaching people at close quarters. They have done great things in the past and have written books and papers that I and many of us have read. They have made practices that have changed the industry commonplace. They are great minds who have changed software development to a great extent, but in lieu of being able to treat folks who come to you with decency, they should probably stop coaching/consulting people and teams.
I had a great time at Agile 2015, met some great people, acquired some great ideas. The sessions, both scheduled talks and most open jams were great. There were some very empathetic coaches and leaders who presented great new ways of helping, inspiring and bringing teams together. It was one bad experience with a couple of grand old men of agile that was the "Purple Cow", but not in a good way. I hope I just caught them on a bad day at a bad time. If that was the case though, they should probably have stayed away from "trying" to provide help. Maybe they should leave that to the other empathetic, bright coaches who are passionate about helping teams and people achieve the best results without coming across as condescending or disinterested. I have to say I met quite a few of those at the conference this year.
What a disappointing experience - I certainly hope there were not 'newbies' to agile that watched this interaction and possibly were turned away by the rigid nature of the responses. Individuals can often get so focused on being 'right' that they lose the ability to relate or listen to others opinions. In my opinion agile's greatest strength is empowering the team. I wonder how quick these two would be 'kicked off the island' of a high performing team that understands how detrimental 'jerks' can be to any team dynamics.
ReplyDeleteThank you for helping people get the information they need. Great stuff as usual. Keep up the great work!!! Offshore development services
ReplyDelete