Agile Craftsmanship Punishment driven development I'm a big fan of agile development. One of the key concepts that I like the most is story point estimation. The best suggestion I ever heard was to estimate the size of your stories in terms of gummy bears (at which point you can come up with possibly one of the best units of progress measurement, gummy bears / iteration), thereby making sure that nobody gets the impression that you're actually quoting any sort of real unit of time. The exact opposite of this is trying to estimate stories in an agile project in terms of hours. All too often, even though these realistically are no more than "ideal hours", they are taken literally by everybody and if a developer doesn't manage to "burn down" 80 hours of development per week, they risk being told to either work harder or estimate better (it's often left ambiguous which solution is preferable), leading to what can possibly best be described as punishment driven development.
Suggested Topics for Definition of Done Discussion Ken Schwaber and the rest of us advocate paying attention to what “done” means for a Product Backlog Item (PBIs, or “stories”). For a lot of programmers (like me), “done” often means “It works on my workstation!” The Scrum Master is charged with advocating a “done” that includes everything else needed to build a potentially-shippable product increment. To avoid nasty surprises at the Sprint Review Meeting, I’d suggest initially attaching a definition of done to each PBI during the estimation process. If you’re using cards, write the definition of done on the cards. Scrum, a generalized framework rather than a defined process, doesn’t prescribe a particular definition of done. However, reading this may save you a couple iterations because the same kinds of things come up a lot. –mj Michael James Software Process Mentor Danube Technologies, Inc. For a general description of Scrum, see the Scrum Reference Card.
Software Craftsmanship So what is software craftsmanship? A better metaphor: In a very simplistic way, we can say that software craftsmanship is a better metaphor for software development than software engineering, as I wrote in a previous post. Software craftsmanship sees software as a craft and compares software developers to the medieval blacksmiths. Wikipedia Definition: is an approach to software development that emphasizes the coding skills of the software developers themselves. I personally don't like too much the Wikipedia's definition. A more personal definition: Software craftsmanship is a long journey to mastery. A software craftsman cares and is proud of his or her work and is extremely professional and pragmatic when it comes to its implementation. The Software Craftsmanship Movement In the manifesto, the essence of the software craftsmanship is capture in its subtitle: Raising the bar. The values of the Software Craftsmanship Movement Not only working software, but also well-crafted software
Inside the Mind of Jeff Bezos Scrum 3.0 and Organization 4.0 - impressions from a great evening with Boris Gloger at ImmobilienScout24 | On the agile path Today I had the opportunity to join a great and inspiring presentation by Boris Gloger talking about Scrum 3.0 and organization 4.0 (thanks to Immobilienscout24 for hosting a great event). With this post I provide a short summary of my notes and insights and links to further posts I already wrote about some topics presented today. Based on an initial blog post by Boris (DE) - we started today with a recap of the Scrum journey from Scrum 1.0, Scrum 2.0 and developed to today's Scrum status. Scrum 1.0 foundation by e.g. Agile Software Development with Scrum (Ken Schwaber)basic meeting artifacts, 3 roles (ScrumMaster as management role, Product Owner and team)retrospective was not yet part of itBacklog idea, but not yet that establishedfocus on deliverysprint idea - a common way to think about what we would like to deliver together, but breaks in between sprintslong Excel-lists with tasks and detailed task estimations What did we learn? Scrum 2.0 Scrum 3.0 Product Owner Dailies NoMeetings Conclusion
Robert Cecil Martin Robert Cecil Martin (born 5 December 1952[1][2]), known colloquially as "Uncle Bob",[3] is an American software consultant and author. Martin has been a software professional since 1970 and an international software consultant since 1990. In 2001, he initiated the meeting of the group that created agile software development from extreme programming techniques.[4] He is also a leading member of the software craftsmanship movement. From 1996 to 1999 he was the editor-in-chief of the C++ Report. Bibliography[edit] Designing Object-Oriented C++ Applications using the Booch Method. See also[edit] References[edit] External links[edit] Agile Manifesto Signatories Personal Sites Talks Clean Coder
10 Mistakes That Software Team Leads Make Roy Os “Ten Mistakes” (as I shall now call it because I’m too lazy to keep typing the whole title), was a talk by Roy Osherove which I went to at Skills Matter. He basically takes us through ten common mistakes he sees team leaders make, and offers some solutions to them. He also looks like Adam Sandler, I kid you not. Adam Sandler Here’s Adam, doing some funny acting, or something. Roy Osherove Here’s Roy delivering a piece to camera… Adam Roy started us off by talking about a number of questions that team leaders might have. How do I convince my team to do XWhat do I do with the bad apple in my team? He said that these were all questions that haunted him for years, and in the rest of the talk he goes on to explain how to answer them. So, we then moved on to the first of the Ten Mistakes… #1 Not Recognising Team Maturity This was a good place to start because much of the talk referred back to the “maturity level” of the team. ChaosLearningSelf-Leading Chaos
Creating Product Owner Success The role of the Product Owner in Scrum is powerful but can be challenging to apply: companies that succeed at it will benefit from a new and healthy relationship between customers (product management) and development, and are likely to experience a competitive advantage. This comes at a price: the effective application of the role often requires organizational changes. This article provides insights into how the Product Owner role can be applied successfully. It helps you understand what it takes to succeed as a Product Owner. Super Glue The Product Owner in Scrum plays an important part. Since the role is typically filled by a customer or product manager, the business has to embrace Scrum too, and make the changes necessary to adapt to it. Job Description Let's have a look at the Product Owner responsibilities in more detail. The Product Owner in Scrum is responsible for understanding and communicating the customer needs. Common Pitfalls The Success Formula Old News Summary Resources Bio