May 10, 2009
You’re the ScrumMaster for organization Foo and you’re working with Team Bar. In the first sprint planning meeting you’re thinking that the team committed too much functionality from Product Backlog. You, the ScrumMaster, reminded the team that they are responsible for committing only functionality that they can complete in a Sprint, and they can drop any functionality that they feel that cannot be completed.
The Team Bar strong believed that they can do so much work. They proceed with the Sprint.
At the sprint review meeting, the team demonstrated the functionality committed. The demo was guided by a script that team members follow consistently and religiously. Stakeholders at the meeting congratulated the team for the work done. At the end of the of the sprint review meeting, you started to play with the functionality delivered by the team and ignored the script they used to try different use cases. The software started to throw exceptions and crashing.
What went wrong?
A) The time spent in Spring Planning Meeting wasn’t enough.
B) The time allotted for Spring Review Meeting wasn’t enough.
C) Team Bar ignored the rule of Sashimi.
D) Everything went ok. What’s the point?
What is you best guess? Why?
May 9, 2009
Yeah, it’s true. I’m in a process of leaning and relearning. Fortunately I have the time to think about the usefulness of things we use in software development. 🙂
This week I came across the question:
“For what are Gantt charts useful?”
And because we live in knowledge the wisdom of the crowds era, I decided to throw an message in LinkedIn’s IT Project Manager group.
Let me start to quote my self in that question:
Are gantt charts useful for software projects?
Software projects are complex not only because the technology but mainly because the human behaviour. Humans collaborate to create solutions for complex problems, are Gantt charts useful to model human behaviour and collaboration?
It seems to me that Gantt charts are well suited for very predictive projects or production lines with machines, and software projects are everything but predictive. What is the point of using a technique that assumes a predictive future in a environment in constant change?
As far as I know, Henry Gantt worked with Frederick Taylor and I assume they had the same way of thinking. Now, if Taylor is a Theory X manager what’s the point to use their tools when you are a theory Y manager? Does it make any sense to use gantt charts to manager projects, specially SW projects?
Additionally, I heard from someone that the first time Henry Gantt introduced what we today know as Gantt charts never used the word projects, mainly because those charts were used to manage assembly and production lines… why are we using Gantt charts to manage the complexity of projects?
These answers led me to think again in the usefulness of Gantt charts. My current opinion about Gantt charts is (as seen in LinkedIn discussion):
Ok, so a Gantt chart is only a communication chart, right? We can think of it as a tool for visual management if the stakeholders are educated in that way, I guess.
I understand that Gantt charts can be used to show critical path/s calculated with CPM (Critical Path Method).A lot of more tools and techniques exists to assist us in creating a tentative schedule, like the critical chain method as William mentioned. But at the end, a Gantt chart is only a tool for communication, right?
IMHO, there’s a risk with Gantt charts
PMI, for instance, as well as Agile Manifesto, promote face-to-face communication. The heavy use of Gantt charts can be seen as a risk when they start to flow, more than desired, through email within your organization.It’s not only a question of everyone seeing different versions of a project, it’s also a question about the wrong message your organization can be passing to stakeholders: email-communication culture is Ok.
I think we’re loosing sight of what its important in projects, the People. So, the use of Gantt charts for communication of project status, progress, etc should be revisited, IMHO. Moreover, I think that a “Go see” culture is the most effective way to access progress.
I’m not against the use of gantt charts in any way. I just have to believe in their utility before using them.
And you, how do you feel about the uselfulness of Gantt charts?
May 6, 2009
Last year I wrote this article where I expressed my feelings about the usefulness of the ScrumMaster. During the last three days I learned a lot useful and funny stuff about Scrum and Lean. I enjoyed leaning that the ScrumMaster is responsible to help the organization change to a more Lean mode of operation where, among other things, teams are self organized and self managed. I’ve also leaned that the ScrumMaster is not useless! ScrumMaster is a temporary but necessary waste!
And if you think about this, it is probably the truth. If you have a truly agile and lean organization for what you need a ScrumMaster? To help in a goal already accomplished?
April 1, 2009
Vendo pelos casos de sucesso da Economia 2.0, parece fazer sentido. Afinal a bolha das empresas “dot-com” pode ter sido causada por uma break-through innovation:
March 24, 2009
Estão a pensar criar uma startup. Querem fazer alguma coisa de diferente e não sabem o quê?
Tim Barry, disse :
So if you’re in the tech world and have capabilities, here are some ideas. Offered to you free, which is, by the way, what an idea is worth. You add technology, management, capital, operations, marketing and getting it all done, and you have a business.
Escolham uma, ou várias de:
Será que resulta?.
O titulo deste post vem de um post do OnStartups.com
March 18, 2009
Esta deve ser a quarta ou quinta vez que organizo as minhas feeds no Google Reader. Utilizo o Google Reader à bastante tempo e por lá já passaram muitas, muitas feeds. O que sempre me incomodou é como as feeds estavam organizadas.
Acredito que muitas pessoas também organizam as suas feeds como eu tinha as minhas organizadas, por assuntos e interesses. Por exemplo:
- Project Management
- Software Development
Aquela organização não estava a funcionar comigo. Já me sentia novamente perdido no meio daquelas informação toda e por vezes tudo aquilo deixava de fazer sentido para mim.
Esta última organização está a funcionar melhor e sinto-me bem com ela. É baseada nos papeis que assumo na minha vida. Por exemplo:
- Business Analyst
- Product Manager
- Project Manager
- Software Engineer
- Technology Manager
Uma simples alteração, mas esta organização permite-me focar aquilo que é importante para cada um dos papeis que assumo na minha vida. Se me quiser informar e desenvolver, em qualquer momento do dia, sobre o meu papel de software developer, então leio apenas a secção “eu sou um developer”.
E vocês como organizam as vossas feeds?
March 17, 2009
Só hoje descobri que a Microsoft já tem a sua plataforma de “Cloud Computing“. Com o Azure Service Platform, os developers podem, como já podem há algum tempo fazer com o Amazon WS, distribuir as suas aplicações na rede.
Windows® Azure is a cloud services operating system that serves as the development, service hosting and service management environment for the Azure Services Platform. Windows Azure provides developers with on-demand compute and storage to host, scale, and manage Web applications on the Internet through Microsoft® data centers
Os developers que se atreveram a experimentar cedo este serviço, já experimentaram também 24 horas (+/-) de quebra de serviço.
Tenho lido bastante sobre as tendênicas do cloud computing, mas estas quebras de serviço não têm ajudado a ganhar a confiança merecida. Talvez por causa disso, algumas estratégias passam por disponibilizar as mesmas aplicações offline, como é o caso do Google Calendar.
Pessoalmente acredito neste novo paradigma que economicamente faz muito sentido e também compreendo todo cepticismo envolvido.
Acho que negar esta realidade pode ser perigoso para as empresas que não reconhecem o cloud computing como uma forma de vantagem competitiva.
O que acham?
March 11, 2009
Para o Outono de 2009, está previsto o lançamento do livro “Agile Product Management – Turning ideas into Winning Products with Scrum“. Na minha opinião, é um livro que faz falta.
Com cada vez mais organizações a adoptarem SCRUM para o desenvolvimento de software, é importante que as responsabilidades do Product Owner sejam clarificadas e entendidas por todos.
De acordo com o autor Roman Pichler, este é um livro para todos os interessados em Agile Product Management, principalmente para os actuais Product Owners ou para quem está a pensar assumir essa função.
Já se podem ler o capítulo 1 e 2, e claro, dar o vosso feedback 🙂