You are currently browsing the category archive for the ‘Agile’ category.
I’m happy to share something that Kent Beck shared with us answering to the post TDD is dead. Long live testing.
What’s I love of Kent’s notes is the fact that he indirectly did a list of the top priorities / skills (/ errors) of a good programmer. Ok probably Kent would argue that this is the list of his priorities but… I like to think is more general than that 🙂
[…] I’m sad […] because now I need to hire new techniques to help me solve many of my problems during programming:
- Over-engineering. I have a tendency to “throw in” functionality I “know” I’m “going to need”. Making one red test green (along with the list of future tests) helps me implement just enough. I need to find a new way to stay focused.
- API feedback. I need to find a new way to get quick feedback about my API decisions.
- Logic errors. I need to find a new way to catch those pesky sense-of-test errors I’m so prone to making.
- Documentation. I need to find a new way to communicate how I expect APIs to be used and to record what I was thinking during development.
- Feeling overwhelmed. I’m really going to miss how, using TDD, even if I couldn’t imagine an implementation I could almost always figure out how to write a test. I need to find a new way to take that next step up the mountain.
- Separate interface from implementation thinking. I have a tendency to pollute API design decisions with implementation speculation. I need to find a new way to separate the two levels of thinking while still providing rapid feedback between them.
- Agreement. I need to find a new way to be precise with a programming partner about what problem I’m solving.
- Anxiety. Perhaps what I’ll miss most is the way TDD gives me an instantaneous “Is Everything Okay?” button.
I’m sure I’ll find other ways to solve all these problems. In time. The pain will fade. Farewell TDD, old friend.
PierG
It’s been said that agile BI is simple but not easy. That is, the concept of working in short iterations, delivering your BI system in small increments, and evolving the solution based on feedback is easy enough for most people to understand. However, as with many things, the devil is in the details.
via Ten Mistakes in Agile BI Adoption.
Sure it is in the details and as far as I see, agile BI is not that easy 🙂
PierG
Most large companies invest heavily in application development, and they do so for a compelling reason: their future might depend on it
via Enhancing the efficiency and effectiveness of application development | McKinsey & Company.
I’m not (at all) impressed by the concept of Use Case Points (count of the number of transactions performed by an application and the number of actors that interact with the application in question) but I loved the sentence 🙂
PierG
It’s ironic that two industries who are highly reliant on collaboration often have the most siloed legacy systems, processes and IT infrastructures. As one aerospace executive told me recently, the industry sees cloud computing as solution to what many call “silos of excellence” that slow down progress. Aerospace executives also speak of security concerns, especially in the area of globally-based defense support and logistics platforms.
full article here
…. mmmmmm: my spider senses are tingling ….
PierG
Limiting the number of projects a team is working on – making the team do less – does not have to reduce productivity and can actually deliver more
via agile42 | Stop Starting and Start Finishing.
PierG
when we look around at the companies who are doing well, it can be hard to see the rhyme or reason of the decisions that led to that success. Take Apple and the work it put into building a technology platform on which hundreds of thousands of independent developers could create apps and offer them to Apple’s customers. Or take Salesforce.com and its willingness to have self-organizing development teams continuously tweaking code, even though, with a global system serving more than two million subscribers, the risks of introducing errors into its 30 million lines of code would seem to present compelling reasons not to. (Drawing on the software development practices known as Agile, Scrum, and XP, the teams work in short, iterative cycles of test-driven development with direct customer feedback as the work proceeds.)
In fact, these companies are not behaving chaotically. They are acting according to a rethinking of the rules to suit today’s business conditions, and learning new heuristics based on their successes.
via Making Management as Simple as Frisbee – Steve Denning – Harvard Business Review.
PierG
People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method. Meeting needs fades in priority
via esther derby associates, inc. » /Estimating/ is often helpful. /Estimates/ are often not..
PierG
A manager has to know when to ignore a precise number. “He has to know that ‘larger’ and ‘smaller,’ ‘earlier’ and ‘later,’ ‘up’ and ‘down’ are quantitative terms and often more accurate, indeed more rigorous, than any specific figures or range of figures.”
via Fat Chance | The Drucker Exchange | Daily Blog by The Drucker Institute.
PierG
IT people is often scared when I say that I don’t like the traditional testing phase in IT projects.
I understand, it’s so relaxing to know that you have a bunch of people to blame when projects go the wrong way: “we did 3 month of testing, we really couldn’t do more to save this project!”.
And if it’s not the testing team, you can always blame the requirements team for gathering them badly. But this is another story, another post :). Let’s get back to testing.
What I generally don’t like about testing is that you do some operations based on … what the system is designed to do. Someone writes a requirement, someone (else) writes one or more test cases to prove it, someone (else) writes some code and finally someone (else) reads the test case and uses the system giving his interpretation of the behavior … giving a GO/NO GO.
Should I explain why I feel uncomfortable? I hope not but let me add an unobvious thing: where is reality in this long chain? Who’s in charge of saying if the system is doing what is needed and not what someone (else) thinks it should be doing?
Scary, isn’t it?
PierG
We will talk about a new development technique called WDD or Worries Driven Development.
You might know another couple of *DD techniques: TDD and DDD but they are by far less powerful than WDD.
TDD or Test Driven Development has been invented by Ken Beck (@kentbeck). As Wikipedia states “is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards”.
DDD or Domain Drive Design is a little more recent, especially it’s hype, and as Wikipedia says “is an approach to develop software for complex needs by connecting the implementation to an evolving model.The premise of domain-driven design is the following: Placing the project’s primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.” In Italy Alberto Barndolini (@ziobrando) is really good at it!
WDD is more powerful because it works at a deeper level. It acts at the level of motivations. We tend to do what we do for one of two reasons: to seek pleasure or to avoid pain.
Now our culture tend to push us to the ‘avoid pain’ side so we tend to use it more often as a motivation to do what we do. So what’s more relieving than solving a problem to ‘avoid pain’?
That’s where WDD come from: we do what worries us. Or better we do, schedule, put in priority what can have consequences that can worry us.
So the algorithm is: if you don’t have it, create a problem, throw it in the future, communicate it so that everybody can be worried. Now you are ready to make a lot of overtime to solve it to ‘avoid pain’.
The secret? WDD is not that new: it is quite often used as a primary development paradigm in many offices of medium-big corporations. And it works …. maybe.
PierG
Subscribe
PierG (aka Piergiorgio Grossi) 