Mike Cohn, founder of Mountain Goat Software and long-time vocal proponent of Scrum is coming to Austin next month as part of the Agile Austin Distinguished Speaker Series. Mike is the author of Agile Estimating and Planning and User Stories Applied for Agile Software Development, among other development/programming books. He's served as technology executive and helped with the adoption of agile processes at various companies.
If you are working on agile teams right now or are just interested in learning about agile methods and agile company adoption and are close enough to Austin on May 8th, then be sure to attend this event for some very highly valuable information. The title of Mike's talk is 'Succeeding With Agile: A Guide to Transition' and will cover such topics as why agile transitions fail as well as discussing several specific ways of getting started with agile and the advantages of each.
Date: May 8, 2008
Time: 6:00 - 8:00 PM
Location: Austin Community College, Highland Business Center Campus, Room 201,0, 5930 Middle Fiskville Rd.
See all of the event information at
http://www.agileaustin.org.
See you there!
There was a break-in at our company the other night. We had some nice products on visible display through the front door in our office's small reception area that evidently made for an easy target of a smash and grab operation. The entire caper was recorded on our internal security video system. The perpetrators (one inside taking things to the door, the other just outside receiving) broke the glass out of the front door and proceeded to carried out the items on display.
At one point during the ~1 minute heist, the thief looked into the conference room just off the reception area near the front door and noticed an LCD projector on the table. He quickly ran into the conference room, grabbed the projector, and dragged it from the building by its cabling.
The buzz in the office the next morning was mainly around the fact that our really crappy LCD projector was now gone and that we finally had the necessary justification to purchase a new projector actually good at, you know, projecting video images and displaying visual information.
Thanks, degenerate criminals!
New Partner
Our company is growing and the processes that support our e-commerce efforts must be ready to grow along with the business. Looking to ensure our abilities to effectively manage this growth, we recently decided to form a strategic partnership with another outfit that will develop, operate, and maintain our various e-commerce sites, as well as replace our internal sales and customer service applications. You could say our company's strength is in quickly executing our e-commerce, marketing, and merchandising initiatives. In other words, we are SaaS'ing our core competencies and processes.
Background
All of our company's technology is totally home grown (except for the usage of Microsoft Commerce Server which our sites were built upon). Up to this point, our internal IT staff has developed, operated, and maintained all of our e-commerce sites. We've also created from scratch the entire suite of applications and tools that serve as the back end operations to our business.
Kick Off
Our partner arrived at our offices last week to officially "kick off" the relationship by discussing the first project we will work together on. The project manager began things by presenting their engagement model and how they run projects with each of their clients. The slide in his deck that helped describe their project process was a very nice looking diagram that appeared to be split up into various phases that included sequential steps, all flowing in a downhill manner, marching toward a completion date ~3 months into the future.
Wait a minute....
hold on here....is that...
yes...I think it is...
that appears to be a....
Waterfall!!!!! NOOOOOO!!!!!!
Their plan included a 3 month project schedule with a ~1 month "iteration" somewhere in the middle. This followed an exhaustive requirements and UI wireframe gathering period where we would sign off on the deliverables. After we waive our ability to change our mind sign off on the requirements, our partner would then go away (this is the iterative part, I guess?) and do the work. At the end of this period, the web site (that's the main deliverable that can be demonstrated) would be unveiled to us and at that point the initial requirements would be open for modification and all bugs will be worked on and fixed until the day the first site launches.
While this was being explained to us, our team (which included all the main business owners within my company as well as a few of us technical guys) immediately began asking about feedback, backlogs, demonstration of working software during the project, communication channels, etc. The responses to our inquiries** served to paint a very clear picture regarding just how Agile our group has been in delivering business value over the past year....and how non-Agile our partner seems to be. At that point, I think we all recognized how good we had it while working as an internal team, co-located and committed to a common purpose for a company we all worked for.
We ARE Agile
Our attempts at delivering working software internally over the past year have followed the Agile/Scrum process. We very much believe in and implement the tenants of the Agile Manifesto. We communicate. We adapt. We don't lock in our stakeholders to agreements, statements, or requests made weeks(months!) in the past. Key implementers don't go away and create solutions for weeks at a time with no customer interaction. We are open and available, not hidden away.We work at a predictable pace.Once we started holding daily stand-ups and displaying our sprint burndowns, our stakeholders became addicted to the constant feedback they receive on the progress of work being completed and business value provided. When we voiced the concerns with our new partner, the response we received was "We don't work that way, but we'll see what we can do...".
Partnership? -- Lessons Learned
Right from the beginning, the relationship can be seen as adversarial, due mainly to a stark contrast in expected communication patterns and a drastic change in how business solutions are collaborated on and delivered for our company. When you ask someone to sign off on something, that's an agreement and a waiver of sorts. That's definitely not a partnership from the outset. It's a transaction.
Please note that I'm not claiming ultimate demise on this new partnership. Clearly, this doesn't mean everything won't work out in the end as very capable professionals at both companies will no doubt do whatever it takes to make this thing succeed. However, it's a tough thing for a company like ours to become pretty good at working in an Agile manner and then turn over implementation to another team from another company in another state that doesn't value the same things as we do.
It's clear that any business today will need to have a solid strategy for how to effectively leverage technology to achieve it's vision. When evaluating these strategic options that include partnering with another company or consulting firm, it's VERY important to keep in mind your company/team culture to ensure that the team concept is not lost in the shuffle. Culture in the situation described in this post means 'the processes, methods, and communication patterns that allow a team to get things done'. Mismatches in culture between companies and teams brings more obstacles to an already difficult task.
Feedback
I'd like to know...how do you think strategic technology partnerships should operate today? What are your success/failure stories? Is it too much to expect third party vendors to adapt to their clients' way of working/culture? What are reasonable expectations here?
** Both the project manager and the technical architect from our partner expressed their company's inability to easily create a tenant's (that's us) environment in isolation so 1) at any moment we can easily see the progress on the deliverables and 2) it can be tested, among the other benefits of having the capability to automate environment/application deployments.