Home » Posts tagged 'culture'
Tag Archives: culture
I don’t think I can fully communicate the value of co-location.
Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.
One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!
When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.
This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:
- No team-specific collaboration space. Had to book meeting rooms and hope one was available.
- The Devs and PM have no whiteboard space. They are in cubicles.
- The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
- PO (Product Owner) and HW (Hardware guy) were alone in their offices.
- There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
- The sponsor was on the opposite side of the building.
For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:
Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.
I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.
I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.
The PostIt notes were used to keep less volatile things like our value statements right up in front of us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.
We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.
I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.
But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.
And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away.
And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can. And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.
I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.
I recently had the privilege to speak that the Calgary .NET User Group’s new lunchtime series. This series is an opportunity for people to come and hear about exciting new topics with a minimal time commitment. And in this case, CNUG President Dave Paquette felt is was about time that we have a talk about Kanban.
Here is a link to the video of my 50+ minute presentation. It’s the first time they’ve video taped one of these, so please don’t be to critical of the quality. 😀
You can find the slides on Slideshare here.
The one thing I’d like to pull out specifically from this presentation was the exercise we went through (11:24 in the video) in understanding what it was we were actually talking about. In my slide deck, I indicated there are three common definitions of kanban out there and that we really needed to understand which one we were talking about in any conversation around the topic. And in an informal little survey of what participants though kanban was, we got the all three definitions from different people in the audience. The three commonly confused definitions are:
- kanban – signboard, visual signal, card
- kanban system – pull-based work(flow) management system, normally at the heart of a kanban method implementation
- Kanban method – An approach to incremental, evolutionary process change for organizations
Very often when I am discussing the Kanban Method with people who are new to any of these ideas, they are often getting them confused and it is really important that we clarify which we are talking about.
Do you know what Kanban you’re talking about? 😀
This is a story about my job, which I love.
During the day, I’m a mild-mannered process consultant (read: Lean/Agile evangelist) for Imaginet, a technology consulting firm that provides end-to-end software development services primarily specializing in Microsoft products and technologies. The really cool thing about Imaginet is that we are large enough to be able to help companies with projects that span the full lifecycle of solutions development, or Application Lifecycle Management as it is more well known. And these projects often involve helping organizations adopt, refine or improve their existing ALM processes.
That is the part that I get excited about. As a process consultant and change agent, I get to help companies take their development processes to the next level and build an organizational culture that is capable of continuing that growth.
It was in this context that our current client engaged us. They were going to build a team that was expected to build a mobile transportation solution that would help them manage a fleet of trucks. This client had never had a core competency in software development but realized that in order to realize their vision, they would need to become competent as there was no off-the-shelf solution that would fit their needs. They did have experience with traditionally managed knowledge work projects and really felt that this was not going to lead to a successful project. There were far too many unknowns and risks and they knew they would need to learn and adapt very quickly throughout the project.
So we all decided to adopt an Agile/Lean mindset and build a process that would help us deliver in this challenging situation.
This long preamble is really just setting the stage for me to share with you what I think were the 5 core principles that we used on this project to ensure that the mindset and methodology development worked and became institutionalized. I’m hoping that by showing you how they affected the way that we work and the benefits, you’ll be able to learn from us and see if they could work for you. This 5-part series won’t be as much about the methodology we ended up with as much as it is about how we ensured that the right methodology for the organization and project emerged and that we maximized our chances of success.
Success Factor 1 – Transparency
The first core principle that we followed was to provide as much transparency into everything that we did, the information that we had and the challenges that we faced. We were so focused on this transparency that it actually tended to border on continuous broadcasting.
In an environment where there is a lot of uncertainty and risk, we felt that it was crucial to our success that we get as much information as possible from as many sources as possible and to engage anyone who could help us succeed. And with a project sponsor who was taking a significant risk in building a new competency for his organization, it was important that he see how we were working, the challenges we faced, and that we were always looking to improve the way that we worked.
To that end, we used numerous tactics to provide as much information on how we were working at a glance to anyone who was interested. These tactics included:
- a big team room which encouraged information sharing and broadcasting
- digital storyboard (work management system) that was projected onto a screen at all times and accessible anytime from a browser
- daily stand-up meetings where anyone was invited to attend
- iteration planning and retrospective meetings every 2 weeks, anyone could attend and the outcomes of these meetings were left in plain sight for anyone to see
- team Skype account that would auto-answer (silently I might add) and project onto the screen, with a live video feed and multiple microphones in the room
- Skype accounts and webcams for all team members
- tons of whiteboards and large post-it notes that we write on continuously – every wall in the room (600+ sq. ft room) was covered in information and updated frequently
- large post-it notes on the wall outside the team room to notify anyone walking past in the hall
- email notification of significant events in the development process (e.g. broken builds, server outages)
And it is working!
Our sponsor, who sits across the hall, frequently comes into the room and sees exactly what the team is doing. Our openness has fostered a culture of trust between him and the team that allows both to ask questions, provide inputs, and make decisions for the good of the project together. And one of the really cool aspects of his interactions with us is that he very rarely comes in and asks us how we are doing or where the project is at. He already knows! He usually comes in asking about a specific item we are working on, or asking if he can help with one of our problems.
We never have to defend our methodology because we are constantly sharing it with everyone and allowing them to participate in its improvement. This is one of the hard parts of an Agile adoption project that is easily avoided by aggressively being transparent.
Another benefit of this level of openness is that when we have brought on a new team member, which has happened several times, they are immediately immersed in a LOT of project information. This ranges from work in progress, upcoming stories, improvement work items from the retrospective and any risks or challenges that we are actively facing. We also have numerous big PostIt notes that contain the values and principles that we have chosen to follow as we evolve our methodology. How we perceive value, prioritize and the core vision for the product is all up on the walls all the time.
We have received help from a variety of people within the organization who saw something that we had on our boards that they could help with. These helpful acts ranged from sharing critical bits of information that helped us make a much better decision to actually removing a roadblock or impediment from our current blockages. And without this level of transparency, there is a good chance that these helpful acts would have been delayed if they had even arrived at all.
Transparency has been, and will continue to be, a significant cultural aspect of our team that we feel helps drive our success.
Do you have any transparency tactics you’d like to share? Please do! Comments and thoughts are always encouraged!
p.s. I plan to enhance this post with pictures soon, but I’m under a deadline to get this out (thanks Dylan) so they’ll have to wait! Please check back in the next couple days.
p.p.s. This blog is being inspired by a competition between a bunch of us to see who fails the blogging frequency requirement first! Please check out the blogs of all these other awesome guys and encourage them to keep on blogging too!
- Success Factor 1 – Transparency
- Success Factor 2 – Visualize Your Work
- Coming soon – Success Factor 3 – Co-location
- Coming soon – Success Factor 4 – Invest In Your Tools
- Coming soon – Success Factor 5 – Retrospectives