Ron Jeffries is well known. He’s so well known that he doesn’t even have to tell you who he is. You should just know. A quick trip to his Twitter page tells you that. #ronjeffries #pwnd
Regardless, we always perk up whenever we read something he has to say. Usually it’s pretty interesting stuff. His latest blog entry tells us that we do not need technical user stories. Period.
Why is that?
Let’s break it down for the rest of us peons, shall we?
“One of the pillars of Scrum is for the Product Owner (PO) to prioritize work for the team, so that the best possible product can be delivered within the desired time and budget. Clearly, the PO is (should be) capable of pinpointing the most value. Therefore, it isn’t too smart for a development team to focus on anything other than what the PO wants.”
Since technical user stories have the promise of providing faster velocity in the future, and are different from the PO’s user stories, you end up having a priority and time dilemma: PO user stories VS. Technical user stories.
Ron Jeffries 3 Reasons to NOT Have Technical User Stories
As developers, we are, at the end of the day, the critical path between completion and non-completion of a project. I mean, let’s face it. If we didn’t do our jobs, all the project managers out there would be out of a job! (I kid, I kid!)
Russ Sherk, a developer at Klocwork, tells us about the 5 biggest ways to waste time as a developer and what to do. Not only does Russ give us the ways to fix the issue, we’d like to add on a couple of pointers on how Agile can help with time-wasting for developers too.
I absolutely love this service. Why? Because I had this idea last year and dang near built it myself! I’m always interested in going to the coolest tech conferences and any local Agile events that I can get to. But there isn’t a really good site out there that provides all of that information.
Denounce: “To publicly declare to be wrong or evil.”
An author (Scott Ambler) on the Dr. Dobbs has recently written a very compelling article on the whole Agile-certification issue.
Very much like Tobias Mayer, who late last year denounced the Scrum Alliance and all of the certifications, Scott calls all CSM’s to denounce their CSM certification.
My hope is that all Certified ScrumMasters (CSMs) will denounce the CSM designation if they haven’t done so already. You attended a workshop; it’s nothing to brag about. Also, if you work for an organization that still wants their agile staff to have the CSM designation then you should help ensure that whoever is inflicting that constraint fully understands what it takes to “earn” the CSM.
My belief is that the Certified Scrum Trainers (CSTs), and the Scrum Alliance in general, can do a lot better. In reality, you’re the ones who need to denounce the CSM scheme and to declare it over.
I’m impressed with the recently formed International Consortium for Agile (ICAgile) and their strategy surrounding agile certification. They appear to be on the right track and my hope is that they find a way to stay on it. Anyone offering agile training services should consider looking into this.
Finally, I’ve said it before and I’ll say it again — The Scrum community, and to a lesser extent the agile community in general, has embarrassed itself by tolerating the CSM scheme. Enough is enough. We can do better, and until we do so, our integrity debt continues to grow.
Are you a Certified Scrum Master (CSM)? What do you think about DENOUNCING your certification?
This past Black Friday 2010 I found myself outside Best Buy in a line all the way around the building in the freezing cold. As I fumbled with the thrown-out Black Friday specials pamphlet I found on the ground I wondered whether this was all worth it. An hour later, I was inside dodging the crowded tables of technology and gadgets galore. My shopping-discernment had all but dissipated into a mere memory and my buyer-rationalization began full force.
It’s easy to rationalize why we should buy something. It’s far easier to weigh the positives than the negatives. I could tell you 10 different reasons why I need the new Macbook Air. But stop me mid-sentence and ask me about the negatives? Be off with you fiend! Maybe if I had @agileforall‘s terrible experience with the new Macbook Air I may not get one…
But sometimes it’s best if we look at the negatives first. Sometimes it’s easier to find out what you want or like, by first, considering what you don’t want or dislike.
That’s what a group of guys did at the 2009 Salt Lake Agile Roundtable did. We like what they had to say.
An interesting article by Geert Bossuyt caught our eye recently about a fresh way to look at the Agile Manifesto, or what he is calling “MoreAgile Manifesto.” We wrote about Agile Manifesto 2.0 before, and we really like the spin that Geert put together, in sum:
Teamwork & responsibility over Individuals and Interaction – You need great individuals and the better they interact the better it is.
Business Value over Working software – Software in itself has no value. It’s what you do with it.
Partnership elaboration over Customer collaboration – Collaborating with your customer is important, but working on a partnership is better.
Prepare for change over Respond to Change – It’s even stronger to create a setting where change is normal.
It will still be free for public projects, non-profits, and educators. So if you’re in this bucket then you should be fine.
$7 per month for up to 3 collaborators across up to 2 private projects, with 1GB of storage for file attachments $18 per month for up to 7 collaborators, up to 4 private projects, 3GB storage, and use of the Get Satisfaction, Lighthouse, and Bugzilla integrations
SSL encryption, Campfire and Twitter notifications, as well as API use is available for all plans. Community support, via http://community.pivotaltracker.com, will continue to be open for all users.
Individual use will continue to be free, with no collaborators, up to 2 private projects, and up to 200MB of storage for file attachments.
More information on pricing is available on the new pricing page.
“At the end of the day, we’re establishing a paid model so that we can keep improving Pivotal Tracker aggressively based on your feedback, add operational capacity, and provide responsive support.” – Dan Podsedly
Ok. I had fun creating this poorly crafted photoshop. But when I came upon a blog that talked about misunderstood IT words the first thing that popped into my head was:
“These kids with gold and diamond grills in their mouths.”
I’m sure they would say that they dont’ misuse gold and diamonds. We (the public) just don’t understand them.
So is “Agile” a misunderstood word? I recently had coffee with a fellow Agile coach, Andrew Fuqua (@andrewmfuqua), and we talked about the necessity for Agile-thought leaders to continue to blog, continue to write, continue to educate. There is a ton of noise out there. Not all of it positive, nor really informative.
Forrester says “Agile Development is rapidly becoming the Norm.” As per their survey report on Agile Development Management Tools, Q2 2010, 35% of the organizations surveyed described Agile as their primary development tool. Another 16% uses iterative development. But make sure you look down the list. There are a ton of other Agile methodologies that exist under the Agile framework.
If your team is doing Scrum or another methodology, understand that there are a lot of others out there. We recently wrote about Dynamic Systems Development Method (DSDM) as a little gem to look into. Make 2011 a year when you reach out beyond what you know about Agile and learn just a little bit more and grow your craft. There is still so much still to learn! Be kaizen about it!
Video journalist Craig Duff took a look inside Facebook’s engineering department for a whole day and we got to see a very Agile process at work. This video came with good timing as we wrote about Mark Zuckerberg and Agile just last week.
“As we get closer to launch we work closer together, data team, engineers, designers.” – Peter Deng, Product Owner of Facebook Profiles
Peter Deng meets with the data team in the afternoon and as a Product Owner works closely with the team giving direction and course correction as needed. Very cool!
“Being all together in one room with PMs, Designers, and Product Owners helps.” – Josh Wiseman, Profile Team Engineering Manager
All the engineers at Facebook enjoy working closely together.
“We try to move very quickly here at Facebook and get user feedback very quickly.” – Peter Deng
Every action by Facebook users are recorded and used by the engineering team to understand how to better build the UI and educate users with educational text. What you’ll find on the Facebook engineering page is exactly that, a very fine-tuned process of collecting data, iterating, changing, and moving quickly to customer needs and demands:
You’ve probably heard that almost 50% of development is re-work, right? Yep, I’ve heard it, but I really wanted to know where this number came from so we did a bit of research. According to the Standish Group, their Chaos Report year after year tells us that IT development work is really near 50% re-work.
Most people ask the question: “WHY IS THIS ACCEPTABLE?”
Then people use a construction analogy: Imagine having a contractor build your new $500,000 home. But then told you they had to re-do 40-50% of it over time costing you well over your budget. You may just sue them.
I simply ask: Why is re-work given such a bad rap? As a developer, re-work is just another way of building quality software incrementally. In software development, re-work is the name of the game and it’s a fact of life for a developer. We can split hairs and have different definitions of “re-work,” but in the end, I believe we should think of re-work as something not to combat, but to embrace and minimize if you can.
You’ll never get rid of re-work. But you can minimize a little of it. For example:
You could just “understand” the real requirement and have it “documented” in a full BRD.
You could daily review the requirement with the Product Owner and make needed changes daily.
You could go through a detailed requirement translation exercise to functional specifications.
You could review functional specifications, design, architectural implications to fine-grained detail.
You could just repeat some/all these steps until zero ambiguity and requirements are fully understood and documented.
You could just code uber fast, deploy it, then fix 50% of the bugs that come out of it in the next iteration.
Sound a bit facetious? You bet. So what’s the answer to re-work? What makes sense in an Agile shop?
This week has been a good one. We launched Agile Scout LIVE and held our very first LIVE interview. A total of 19 people showed up for the webcast simultaneously. That isn’t that bad considering we just launched and dropped a Twitter and RSS note just hours before the actual event.
The first live interview went very well, aside from a couple of A/V issues in the beginning. No worries!
As the need for business intelligence grows, companies need ways to make smarter decisions based on historical, current, and predictive data. Business intelligence (BI) isn’t just reporting. Better business intelligence is better decision-making. Sometimes called a decision support system (DSS), the way BI systems are built can have major impacts on the way a business moves and adjusts to demanding market conditions.
Sounds like serious business? Yes, it can be.
Sean McClowry tells us that it is about time for Agile BI to take the stage-front. Since Agile prides itself in collaboration, frequent releases, accommodating change, and relentlessly managing scope, it just makes sense that as BI becomes more important to businesses, an Agile approach should be the way to go.
“BI professionals have long been advocates of 90-day increments… However, incremental isn’t agile no matter how short the increments or how fast the iterations. The agile difference is in participation and interaction–not just building things quickly, but building the right things quickly. The participative model of agile brings with it the promise of breaking away from the “just another report” syndrome that plagues virtually every BI team.” – Sean McClowry
We don’t often hear about the trials and tribulations of a technical writer. Frankly, that’s a space that may need more bloggers like Giri from IWorkAsATechnicalWriter.com to provide more valuable free content for other professional technical writers.
In Scrum, for example, we only really hear about three main players: The Scrum Team, the Product Owner, and the ScrumMaster. What about other players? In some businesses, technical writers are crucial to the entire process as they design, write, create, maintain, and update technical documentation.
What is interesting here is that there is a larger idea at stake: The idea of documentation for companies that run their businesses in an Agile manner.
Ever work for the government or DoD? What’s that documentation process look like? Doing Agile on a major security project that needs tons of documentation on development for audit reasons? Ah, the list can go on and on.
So how in the heck do you update and maintain technical documentation in an Agile environment when everything is subject to change?