|
Written by Bob Aiello
|
|
Configuration Management usually focuses on source code management, build and release engineering with automated deployment. Data is often left to the business analysts and DBAs who focus entirely on data every day. I am seeing an interesting trend where data is becoming an essential consideration for CM gurus to consider. First and foremost is the fact that data can involve complex configuration management. The configuration of many systems is being driven by hundreds, if not thousands, of XML based configuration and property files. Getting these configuration exactly correct is no small task.
I am also seeing a strong focus on disguising data to produce robust and useful test data that does not contain any confidential information. Data has not always been the main concern of CM gurus - but it is now! What other ways does data impact configuration management? Why don't we have standards for the configuration management of data?
What do you think? What's your experience?
Bob Aiello
Editor in Chief
CM Crossroads |
|
Written by Johanna
|
In my post, When You Have No Product Owner at All, I said That’s because agile needs a responsible person who is not part of the cross-functional technical team to rank the backlog so the team knows the order of … Continue reading → |
Once upon a time there was a chicken and pig walking down the country road. The chicken turns to the pig and says, “I have a great idea! Let’s start a breakfast restaurant called Ham-n-Eggs”. The pig thinks for a moment, and then says, “No thank you. You would just contribute (your eggs) and could leave when you wanted to, while my bacon would be on the line”.
This humorous yet telling analogy from the Agile world helps us distinguish those that are just involved from those that are truly committed on an Agile team. However, in the real world, pigs do have to work with chickens and even other animals around the farm. Let’s take a look at each animal more closely. I have seen or heard about the Pig, Chicken, Fox, and Seagull before and I will also introduce a few more new animals (e.g., Rat, Cat, and Bull) to this interesting analogy. How many of these have you seen in your Agile workplace? Pig - They are fully dedicated to the project and the Agile team. They are committed to the work. They work in a pig-pen with other pigs who love their work and environment and love to pitch-in. If Agile is being implemented correctly, they are more than willing to put their bacon-on-the-line every day because they feel ownership of the work. They are assertive and accountable for the success of the project and have a majority (if not all) of their performance goals linked directly to the success of the project and their specific Agile team. Chickens – They come and go on the project. While chickens are mostly helpful, because they are contributing their eggs, they don’t always understand the full context because they are not a dedicated team member. So occasionally they may accidently contribute a rotten egg. They are not accountable for the success of the project, although they may have a small portion of their performance goals linked to the success of the project. Fox – They like to stealthily move into and through the team seeing who has certain skills and ideas. Then they like to steal not only resources (Agile team members) for their own teams, but they also steal ideas. They are not necessarily negative, because they are often so quiet in their manipulative work. They are dedicated to their own success. Seagulls - They like to fly around the project and not really contribute in any manner. They enjoy “talking” (mostly hearing themselves speak) and pretend they are adding value, but they are only annoying the pigs (Agile team members). Often, they like to swoop in so it can look like they are involved (and they’ll tell others this). They are often quite negative, squawk a lot in a “know it all” manner, and often poop on people and their ideas. Rat –They are deceiver types who will use the trust of the team to gain insight into topics so they can then “rat” on what is going on to others. Often on Agile teams, they are really deceivers because they are really anti-Agile or just plain negative people. They often know the decisions that are made based on certain contexts that the team is in, but will twist the truth in order to bring the project down. It is important to identify these deceivers as quickly as possible and get them off the team. Cat – They are a lazy type on an Agile team that really do not pitch in but instead like to sleep instead. They are almost purposefully not assertive, have been used to just “getting by” on projects for years, and are not really interested in feeling ownership of the work. They typically neither positive nor negative and simply like to be left alone. The other team members will begin to notice this behavior and realize they are not really interested in becoming part of the team. Bull – They are command-and-control types (often management) who think they can continue to tell their folks what to do even though they are dedicated to their Agile teams. Sometimes referred to as bullies, they charge right into the team and attempt to direct them to their own work and often deviate the team from building product functionality. Typically, they are not interested in the Agile mindset because they see it as a challenge to their authority (technical or managerial) or don’t really understand or care about the business benefits of Agile, but instead want to maintain their own status. I hope you enjoyed these animal analogies. Did you recognize any of them? What Agile animals are on your Agile farm? Here are few more links to other Agile animal references: Enjoy!  |
|
Written by Administrator
|
|
Source code control is one of those topics that can cause some software developers to sweat profusely and make the veins to pop out of their necks, especially if the project includes working with third-party or vendor code – and these days, what project doesn’t include vendor code? I should probably start by defining source code [...] |
|
Written by Johanna
|
What happens when you have no product owner at all? How does a team know what features to develop in what order? Several teams I know encountered this. They all had product managers. Most of them had BAs. All of … Continue reading → |
|
Written by Administrator
|
|
I’m very excited about our 5.2 release! We’ve completed the move to PostgreSQL on the back end, fully internationalized our products, and added a slew of new features, like per-element security so that you can lock down certain files or directories to specific groups or users. In addition to moving to PostgreSQL, we’ve taken advantage [...] |
|
Written by Johanna
|
I prepare for my speaking and workshop engagements. This year, I’ve been all over the world. I’ve had a great time, and my clients and audiences have had a great time, too. Well, except for this past week at my … Continue reading → |
In the last episode (e.g., Part 3 of 9) of this series, I introduced the importance of the Agile and CM mindset. One of the key elements in CIB involves an Agile and CM mindset change to think more continuously. For Continuous Integration and Build to work effectively it is also important to ensure we are breaking down the work into bite-size stories and/or tasks to ensure we can have a potentially shippable increment. Let’s examine this in more detail. In order to do continuous integration, you need to have the work broken-down into a size of work where you can integrate and build frequently. The ability to specify the right ‘‘bite-size’’ level of story represents change that allow for granular and frequent code changes. This implies that the Agile team has the skills to understand the stories well enough in order to effectively break them down into small and consumable chunks. This allows the team to make codes changes frequently and incrementally. But what are some techniques that help you break down work into bite-size stories? Here are a few ideas:
• Phrase your stories following the Canonical form. A canonical form for a story is expressed as "As a I want to a so that ". This allows work to be segmented into actor, action, and benefit which helps in breaking down the work.
• Utilize the INVEST approach which stands for making a story Independent, Negotiable, Valuable, Estimable, Small, and Testable (established by Bill Wake). This approach helps us split larger stories or work into smaller bite-sized stories. Here are more details: I - Independent can stand on its own and could be demo’able N - Negotiable indicates that stories are negotiable and can be adjusted V- Valuable to the users and customer E- Estimable so that the stories can be sized S – Small enough to be bite-sized T – Testable so they can be verified and validated to work as written.
• Utilize the Use Case method that helps you break down work into functional steps. Each step should produce a piece of functionality. By using this approach, it provides you a basis for reviewing and determining the value of the functionality from each use case step in the flow. This then allows you to establish a more bite-sized approach to the work using a value and/or priority approach.
As you move to Continuous Integration and Build, your team must have the skills to chunk out the work into bite-sized pieces, in this case into stories that can be done within half the size of a sprint. This makes continuous integration and build meaningful and allows for more frequent merging and building of the work. Stay tuned for the next episode where we will focus on the Right-sizing your Branching and what this means in a Continuous Integration and Build process. Note: If you started with this entry (Part 4), consider reading the first 3 earlier blog entries in this series. Note: consider reading Adapting Configuration Management for Agile Teams, consider by Mario E. Moreira Wiley Publishing, 2010 for more information on this topic.  |
|
Written by Administrator
|
|
AccuRev is going to Agile 2011! Stop by the AccuRev booth to say hello, enter to win our great give-away, or see the new AccuRev version 5.2 demoed. Session hopping? Make sure you attend Damon Poole’s session, Scrum and Kanban, Like Chocolate and Peanut Butter on Wednesday, August 10th, at 3:30 PM in Imperial Ballroom [...] |
|
Written by Johanna
|
I recently spoke with a colleague who’s a little confused. John was just promoted to being the development manager in a small organization. He’s used to doing lots of work—whatever needs to be done, he does. Now, he’s managing 6 … Continue reading → |
|
Written by Johanna
|
Every so often, my blog gets plagiarized. I do a whois, find the offending party, have a short email conversation, and get that person to remove my content, and forget the whole thing ever happened. Not now. Right now, I’m … Continue reading → |
|
Written by Johanna
|
For those of you who follow All Things Agile, SQE has acquired Agile Journal. And, with that acquisition, comes a few changes. Russell Pannone, our agile buddy, has stepped away as editor-in-chief. Russell is irreplaceable. I’m not replacing him as … Continue reading → |
|
Written by Johanna
|
Because I’m a consultant, I receive emails with a question, “Do you consult in <fill in this blank>?” Many times I do. But the real question is. “What is your objective?” or “Why do you want to do <this thing>?” … Continue reading → |
|
Written by Administrator
|
|
I mentioned on this blog last week that AccuRev had big news coming that would mark the next phase in the evolution of SCM – the first big leap since AccuRev introduced the stream-based approach. Well, the big news has arrived with this week’s launch of AccuRev SCM Version 5.2. AccuRev Version 5.2 arms developers [...] |
Gaining periodic customer feedback of working software is an important aspect of agile development, because it ensures that you are constructing a valuable solution for the customer. Without customer validation, you are not really applying agile; you are just doing a form of iterative development without aligning your work with the customer’s need. While the engineering practices applied within an agile project focus on building the product right, the validation practices focus on building the right product. The notion of thinking through and establishing a serious validation approach for the product, which I term the Agile Customer Validation Vision (ACVV), is missing from agile projects—and even missing within the bailiwick of agile practices. This vision is a strategy for identifying the right customers, establishing validation sessions throughout the project, and then motivating the customers to attend the validation sessions. Establish Customer Profiles Customer profiles are important to a successful implementation of customer validation. A customer profile identifies common traits in your target customers, including demographics, buying patterns, and areas of interest. The goal is to identify and select customers who meet the profile you are looking for and who are willing to provide feedback. Motivate Customers to Attend Start by inviting customers to just one end-of-sprint review or demo session and getting their input. Customers who have not experienced something like this before typically are impressed to see working software so early in a release lifecycle. If they like the first validation session, then invite them to the next end-of-sprint review and excite them by highlighting where you’ve incorporated their input. At this point, ask the customers if they want to participate periodically at a per-sprint cadence. Consider Various Types of Customer Validation
While there is significant benefit to the end-of-sprint review or demo, the customer is, in most cases, only viewing the working software at that point. Let us review the potential types of customer validation sessions and their attributes in more detail. • End-of-Sprint Review/Demo—This is a type of validation that demonstrates the working software completed during the sprint, shown to customers in order to both highlight progress and gain the all-important customer feedback. • Hands-on Experience—This is a type of validation where customers will exercise the software in a hands-on manner in a simulated or pilot working environment. • On-premise Installation Validation—this is a type of validation where customers physically install the working software into their environment. Once you have established the Agile Customer Validation Vision, it is important to share it with the team so that everyone is aware of the vision and the importance of the validation activities.  |
|
|
Blogs
