When conduction Agile, here's a list of 7 deadly sins to avoid:
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Agile selling retail
| Yet another adoption of Agile outside of software development presents itself again with this article on how a retail outlet called "Oddyssea" based in Half Moon Bay, CA, used Agile development principles to deploy their retail operations: On July 14, 2012, Oddyssea, a first-of-its-kind retailer, opened in Half Moon Bay, Calif. Equal parts science, nature, games, magic and furnishings, with a generous dash of whimsy, Oddyssea thematically is dedicated to exploring, creating and discovering. What’s most interesting about the Oddyssea retail experience is it was conceptualized, designed, implemented and continues to operate using Agile. The Agile software engineering model. But Agile is unrelated to the store’s point of sale, inventory management or financial systems. Rather, it’s completely focused on defining the retail experience... to build a retail operation that was flexible and open to customers, collaborative with his target market and, most importantly, change ready. Leveraging the principles of Agile from software development, they customized the methods for:
I recommend reading the article if you are interested in seeing how Agile is crossing over the boundaries of software development to the development now of retail outlets! |
Posted on: October 05, 2012 11:43 PM
| Permalink |
Comments (1)
An Agile PMO that’s cloudy too?
|
I found this interesting article on the Executive Brief website. It advocates integrating the cloud computing service model and agile approaches to bring IT into the business. This is to deliver solutions irrespective of an IT group's ability and despite their governance (or lack thereof) processes.
As the author Mark Thiele states,
I can’t remember how many times I’ve bemoaned the fact that the business didn’t effectively consider IT before making a decision... The business should be able to forget IT, they should be able to look at the business opportunity and determine its viability solely on its merits, not on whether IT can keep up. However, I’m not trying to say IT should become invisible. On the contrary, the need to have IT working “in” the business has never been more important. Who better to translate a business process or work effort into a potential IT solution than someone who understands how IT can be applied?
The article goes on to outline a more “fluid IT” model that has both aspects of both Agile and cloud computing services that he outlines as follows:
In my view, I could see the above used as a basis for an Agile PMO using a cloud computing deployment model. I’d rephrase Thiele’s outline like this
Could this make for a more “fluid” PMO? Or is this idea too idealistic, or worse, just another instance of more buzz words and overhyped technical solutions masquerading as a viable solution?
As always, I welcome your feedback whether positive, negative or indifferent!
|
Posted on: September 28, 2012 03:08 PM
| Permalink |
Comments (1)
Do traditional PMOs promote mediocrity? Could an Agile PMO do better?
|
Let's be frank, the whole idea of self-organizing, cross functional teams rest on the assumption that you have a stellar kick-butt team. Only the cream of the crop teams will provide you the mechanism to realize Agile to the fullest. Agile was designed for experienced, intelligent, and high-achieving people where you could give them any project, with a streamlined and adaptive method, and they would succeed. This is why teams typically comprise 3 - 7 members that are co-located.
And this is why scaling Agile starts to get difficult. If you have a large and physically dispersed team, you will inevitably have to start adopting some form of documented processes and governance to ensure and maintain standards that are explicit and clear to all involved. Without this in place, you will not facilitate one of the main ingredients to Agile success, namely complete transparency. Furthermore, you will have a bunch of self-organizing scrum of scrums with no direction leading to non-organized chaos. At least with some standards and governance in place, you would have organized chaos.
This leads me to my next irony: Are traditional PMOs inherently setup to encourage mediocrity? When an organization starts to get really large and feels the need to centralize, standardize and maintain consistent standards and processes is when PMOs typically get created. At this point the organization is in a sustaining mode and would not encourage the experimental, adaptive and flexible mindset encouraged by Agile, but would rather promote plodding, yet consistent mediocrity. I'm not saying this is bad, as I have been in large organizations where obtaining mediocre results on a consistent and timely basis would have been heaven!
Its very similar to when a hot startup company grows up and matures into major corporation and goes from disruptor to sustainer. I don't think this is always the case, as Google and Apple are both examples of established Fortune 100 companies that still do innovative things, but I don't think it’s typical.
So the question remains, how do we reconcile scale and standardization with flexibility and agility? Is the idea of an Agile PMO an oxymoron?
So the question remains, how do we reconcile scale and standards with flexibility and agility? Is the idea of an Agile PMO an oxymoron?Let's be frank, the whole idea of self-organizing, cross functional teams rest on the assumption that you have a stellar kick-butt team. Only the cream of the crop teams will provide you the mechanism to realize Agile to the fullest. Agile was designed for experienced, intelligent, and high-achieving people where you could give them any project, with a streamlined and adaptive method, and they would succeed. This is why teams typically comprise 3 - 7 members that are co-located.
And this is why scaling Agile starts to get difficult. If you have a large and physically dispersed team, you will inevitably have to start adopting some form of documented processes and governance to ensure and maintain standards that is explicit and clear to all involved. Without this in place, you will not facilitate one of the main ingredients to Agile success, namely complete transparency. Furthermore, you will have a bunch of self-organizing scrum of scrums with no direction leading to non-organized chaos. At least with some standards and governance in place, you would have organized chaos.
This leads me to my next irony: Are traditional PMOs inherently setup to encourage mediocrity? When an organization starts to get really large and feels the need to centralize, standardize and maintain consistent standards and processes is when PMOs typically get created. At this point the organization is in a sustaining mode and would not encourage the experimental, adaptive and flexible mindset encouraged by Agile.
Its very similar to when a hot startup company grows up and matures into major corporation and goes from disruptor to sustainer. I don't think this is always the case, as Google and Apple are both examples of established Fortune 100 companies that still do innovative things, but I don't think it’s typical.
So the question remains, how do we reconcile scale and standards with flexibility and agility? Is the idea of an Agile PMO an oxymoron?
|
Posted on: September 21, 2012 07:23 PM
| Permalink |
Comments (6)
Kanban as a replacement for the PMO?
| Here's a webcast of a very interesting talk given at the Lean Software and Systems Conference 2012 by David Joyce in which he argues for a Lean/Agile PMO using Kanban to go beyond the tranditional PMO in managing a portfolio of software/IT projects. As the kenote summary states:
Even though traditional models and assumptions represent thinking that originated in the 1890s with Taylor (fixation on efficiency and utilisation) and Gantt (of Gantt chart fame) they seem remarkably impervious to change. What is advocated is quite a big idea to take Kanban techniques which have their roots in Lean and just-in-time production, to create a hybrid Agile/Lean Kanban board driven PMO. This is the kind of convergence of Agile that I mentioned in my previous article, that will re-contextualize these techniques going forward. The author has not allowed the webcast to be embeded so you will have to visit the link to view it directly. But I also find a presentation below which seems to be the genesis of these ideas:
|
Posted on: September 15, 2012 01:43 PM
| Permalink |
Comments (6)
The 7 deadly sins of Agile
|
1. Forget to get early feedback – It’s important to get feedback early on for items such as user stories, product requirements, Agile charter, etc. to your reviewers as early as you can. This will save having to do multiple rewrites. 2. Avoid rather than embrace change – Despite being a practice and method developed to accommodate change the most, you may still find resistance to change especially if your team and customer are accommodated to having requirements upfront. You have to foster an environment where embracing change is viewed as an opportunity to provide value to your customers rather than something to be avoided. 3. Order and prioritize intermittently – You have to pursue ordering and prioritizing your product requirements, backlog tasks and daily activities relentlessly. This will allow you to distinguish the must-haves from the should-haves and won’t haves. 4. Favor remote over direct interactions – With the plethora of electronic mediums to communicate (mobile, IM, social networking, etc.) and an increasingly globalized workforce, it becomes easy to favor remote over direct interactions. Don’t get lazy and get your teams to actually stand-up and talk during stand-up meeting as much as you can! 5. Put off total transparency – Agile is great at revealing and making any problems and issues you have in your projects visible. It is up to you and your team to proactively manage and act on them. To be Agile is to embrace total transparency. 6. Forget to experiment and learn – We can get so focused on delivering the project that we forget to experiment and learn to continually improve. Use retrospectives to collaborate and document lessons learned and allow teams to not be afraid to experiment, test and learn as many novel solutions to pressing project problems get solved during these brainstorms. 7. Deliver work that does not provide true customer value – Though it’s both a very explicit and implicit goal of Agile to deliver customer value, you and your team can get easily side tracked into tasks that won’t contribute to customer value and take up a lot of valuable time and effort. Your team can get too involved with optimizing or tweaking a software feature that’s technical interesting, but will be of little value to your customer. Don’t get too involved with fancy burn down charts or progress reports, but spend just enough time to clearly and concisely articulate the status of your project to keep you stakeholders in the loop. |
Posted on: September 07, 2012 10:17 PM
| Permalink |
Comments (4)