Software Engineering, Project Management, and Effectiveness
I've seen a few customers asking how to structure projects for Team Foundation Server. I don't blame them. Finding a structure that works well for you can be tricky, particularly if you don't have the benefit of hind-sight or a bunch of reference examples to draw from.
My team spent some time this past week evaluating various approaches and lessons learned from various projects We boiled it down to something that seems to be working well, and distills what's worked for some teams. With the caveat that we're still evaluating, here's what we learned ...
SolutionLocal File System
Source Control (Team Foundation Server)
Key pointsHere's a few highlights about this approach:
Repro StepsHere's a brief walkthrough to test using a file-based Web:
Verify your folder structure on your File System:
Adding to TFS
Verify your folder structure in Source Control Explorer
More InformationYou should know that while I talked through the single solution scenario, there are additional patterns. Here's the key patterns we see:
You can find more on these patterns at Team Development with Visual Studio .NET and Visual SourceSafe. You should also know that we have a few How Tos on structuring your projects coming your way. We'll post them to our VSTS Guidance Project.
Share Your StoryIf you've got lessons learned the hard way or practices to share, I'd like to hear them. Now's a great time to share since we're actively building guidance. Either comment here or write a post and leave a link.
Web 2.0 means a lot of things to different people. For me, it means moving from a read-only, one-way Web to a read-write, conversational Web. I think the most exciting part is the shift from sites serving content to humans driving the experience. The machine is us! Where will we take us next?
For a short, thought-provoking video, watch Web 2.0 ... The Machine is Us/ing Us.
The next time I need to get a set of requirements, I'm simply going to start with roles with goals.
I made the mistake of asking for a set of scenarios. What I ended up with is a list of user tasks. Tasks aren't the same as goals. Flying a kite is not the same as having a goal to discover electricity. One is what you're doing, the other is what you want to accomplish.
Since I didn't have the benefit of direct customer interaction for this case, I'm using that as a challenge. What is the most precise, reliable way to get the information need? Roles with goals. I realized, iterating on a list of roles with goals, would get me closer, faster. I can always drill into the stories or scenarios from the goals. The reverse doesn't seem to be true.
David Anderson distills his software management learnings down into four bullets:
He names this set a recipe for sucess. Here's what the recipe mean to me.
Focus on Quality. For me, focusing on quality means pushing quality upstream, and choosing quality over scope or quantity. It also means quality isn't somebody else's job.
Reduce work-in-progress. Reduce work-in-progress really hits home. Carrying too much in-flight work leads to excessive task-switching and administrative overhead. In the buffet of work to be done, frequent small plates, wins over the single, large plate that over-floweth.
Balance capacity against demand. Thinking in terms of demand, helps me right-size execution. Specifically, it helps me think in terms of frequency (how often do I need to deliver value), size (how big does the value need to be), and quality (what does good enough look like now versus perfect down the road).
Prioritize. There's always more work than we can possibly do. To prioritize problems, I think about pervasiveness and impact. Sometimes I need to prioritize a lesser problem that hits more people, over a bigger problem that hits few. I also keep my teams focused on value delivered vs. work completed. It's a subtle shift in mindset, but it makes all the difference.
In my 30 Day Improvement Sprints post, a reader asked, what tips do I have to make 30 days sprints more effective. Here's my short list
Few problems withstand sustained focus. There's a bit of captive genius in everyone that just needs to be uncorked. 30 days of focused improvement seems to be a great way to pop the cork. I'm finding improvement sprints refreshing because I now have a schedule for exploration. I can rotate through more interests. Most importantly, rather than tackle everything all at once, I just wait for my next 30 day focus. It's easier to put something aside for the moment, if I know I'll have a chance to immerse myself in it in the future. If I enjoyed something so much and I want to continue, I just do another 30 days.
Hope that helps!
Here's a simple set of perspectives I use for rationalizing requirements:
Believe it or not, simply identifying these perspective helps a lot. You'd be surprised how many debates happen simply because nobody explicitly identified the source or perspective of the requirement. You'd also be surprised how quickly this helps you make more deliberate decisions and understand what you trade.
How does this help? Your business goals might be a n orders per hour. Meanwhile, your user wants sub-second response time. Well, that's what your users want, but what will they tolerate? Can your business afford the resources for an idealistic experience? Design is always about trade-offs.
In practice, I generally see industry/standards trump business trump expert/technical, trump user. Unfortunately, a lot of software has unconsciously catered to the expert/tech/business at the expense of it's users -- making a lousy experience. On the flip side, some software has catered to users at the expense of the business or industry goals. See the dilema?
You can make a difference. If you build software, know the perspectives, know the goals, and know the scenarios. In some contexts, some tech/expert reccomendations simply do not make sense. Know what you're optimizing. In some scenarios, industry/standards reign, while in others user experience is king. Make sure you have the right representation at the table. Don't ask your patient to prescribe the medicine, or your doctor to rate the taste.
I'm using 30 day improvement sprints as a way to sharpen my skills. I pick a focus to work on and I committ to improving it for a 30 day timebox. Committing to 30 days of improvement in a focused area, is easier to swallow than changing for life. However, improving an area for 30 days, is actually life changing.
With 30 days, persistence and time are on my side. It's a big enough time box that I can try different techniques, while building proficiency. Using 30 days makes working through hurdles easier too. A lot of the hurldles I hit in my first week, are gone by week 2. Little improvements each day, add up quickly. I look back on how many things I tried for a week and stopped thinking I hadn't made progress. The trick was, I didn't get to week 2 to see my results. Lesson learned!
Prashant Bansode has stepped up to the blogging plate. He's been a core member of my team for a few years. I first met Prashant, when he reviewed our Improving .NET Performance and Scalability. I was impressed by his attention to detail, focus on the customer, and keeping things real. Next, we teamed up on .NET 2.0 Securirty Guidance, exploring new models for more consumable guidance. During this adventure, I found that Prashant was a developer who could do it and write about it -- a trait I value. Our next adventure was Guidance Explorer -- an R&D experiment around building tooling to help change the guidance game. We learned a lot about innovation, distributed teams, scenario-driven engineering, and shipping software incrementally and iteratively. Our latest adventures include learning how to build guidance projects on CodePlex: Performance Testing Guidance and Visual Studio Team System Guidance.
Prashant has worn many hats throughout our adventures together -- developer, tester, writer, mentor ... you name it. He's a true case of student becomes the teacher. Be sure to stop by and say Hi to Prashant at his new blog: PAB's World (Prashant uses his initials).
Today I got some relevant training for today's world - how to succeed when you don't have authority and control over execution. This is a common scenario in cross-team, cross-group scenarios. At Microsoft, you don't get rewarded by saying, "...if only I had control over authority and execution ... I would be successful."
At the heart of the class was the model of influence without authority:
You obviously deal with relationships throughout the process. If you assume those you need to influence are allies, you're in a more resourceful state. If you don't clarify goals or understand the world of those you influence, then you can miss out on finding mutual purpose or understanding why or where you get stuck. Currency is more than money; it's any type of exchangable value, such as expertise, resources, ... etc.
I liked the class. The ideas weren't brand new, but instead of sit back and think, it was roll up our sleeves and apply the tools.
When Ward Cunningham was on our team, I learned a lot about building Wikis. He walked me through my first Wiki page. He probably didn't expect that 4 days later, I'd have more than 500 Wiki pages (he added a counter to my wiki!)
Ward told me Wiki Wiki was Hawaiin for fast, and he wanted to simplify publishing (the writeable web). This explained away my initial complaints of formatting and features, and I adopted the mindset of shapable content you can evolve over time. I thought of Wikis as notepad for the Web.
Ward and I had a lot of insightful conversations around various Wiki issues: one Wiki vs. many, choosing namespaces, choosing names, collaboration ... etc. The most important lesson for me was to think in terms of great pages. This meant, choosing better page names and make pages that matter. How to eat an elephant? ... one bite at a time. How to build a useful Wiki? ... one page at a time.
Today ends my 30 day experiment eating living foods. I'm a burger and pizza boy at heart, so this was a big change. Friends and family noticed my slimmer look and healthy glow. A friend of mine said I found the Fountain of Youth.
Here's what I noticed:
I didn't expect to shed my skin so that surprised me, but I liked what was underneath. I was also surprised by how some issues were dietary vs. natural. Nature vs. nurture strikes again!
Friends asked me what practices I'll carry forward:
Most importantly, I learned how to effectively do living foods for 30 days. This means, I can choose to do 30 day tune ups throughout the year. What I walk away with is a better idea of how foods affect me, how to balance my bad foods with good, and how to tune my body when I get run down (or need to fend the flu season).
We're such thinking, feeling, doing creatures at heart and food has such a big impact on the way we think and feel. I'm going to explore more options. A friend of mine suggested testing intuitive eating, where you eat what your body craves, not what you mind thinks it wants.
In Now THAT's What I'm Talking About! , Andrew McAfee writes about a case study of deep Enterprise 2.0 penetration:
"Highly popular, and highly useful. I find that the sites I visit most often these days are ones that give me 'the latest.' They help me stay on top of (or at least feel like I'm staying on top of) the world, the blogosphere, and my personal network of people and content. This page does the same thing at the company level for AARF employees. It gives them 'the latest' about their work environment. And it does so in a bottom-up and egalitarian fashion. This page doesn't contain the latest information that the company's senior managers, or its IT staffers, think employees should know about; it contains the latest information that employees think employees should know about."
I updated our index of Team System MVPs index today so that my guidance team can quickly see the profiles and blogs. I couldn't find some blogs, but I'll add them as I find them over time.
I like how Most Business Tech Pros Wary About Web 2.0 Tools In Business summarizes a Web 2.0 + Enterprise world ...
"Enterprise 2.0 can't just be about a wiki here, a blog there forever. Taken together, the emergence and convergence of Web 2.0 and IP communications is what will determine whether there's truly an Enterprise 2.0. It's a new architecture defined by easier, faster, and contextual organization of and access to information, expertise, and business contacts--whether co-workers, partners, or customers. And all with a degree of personalization sprinkled in."
Imagine what a Guidance 2.0 world might be like ...
I think next-gen guidance is about bringing together a lot of key concepts:
A lot of today's guidance lives in blogs. Part of the problem (and beauty) of blogs is that every end node is a blob of information. What if there were RSS end nodes that contained "collections" or "lists" of how tos, guidelines, patterns ... etc.? From a very practical standpoint, I would love to subscribe to the latest MS (or any company) recommendations and view those in a type of my choice (patterns, guidelines, how tos ... etc.) The mashupability is endless.
Those are the ideas that drove and shaped Guidance Explorer. Guidance Explorer was just one small step towards a world of more effective and efficient guidance.
This is our first release of our Visual Studio Team System Guidance. This project is a collaborative effort with VSTS team members, customers, field, and industry experts.
What you'll see so far, is Practices at a Glance and Questions and Answers as we're tackling source control / versioning. They are designed to give you a quick path through the lessons learned and emerging practices. These are works in progress. As we learn, we update. What you'll also see is a section that includes artifacts we create to help us build the guidance. You'll also see a Team System Resources Index which is lists of the various public resources we use. One of the first things steps we took to ramp our team, was gather and catalog the available resources. There are a lot!
Once we tackle source control, we'll be moving through other high priority areas, such as build, work items, and reporting. We're evaluating customer success using scenarios, organized as Scenario Frames. Here's our emerging Source Control Scenario Frame. The working plan at this point is to build community around our Visual Studio Team System Guidance, while we tune and prune our guidance. We have a fast publishing path in CodePlex and we can experiment with usability and various guidance form factors. As the guidance matures, we can make key guidance broadly available in the MSDN library.
Our team includes previous members from security and performance guidance: Alex Mackman, Jason Taylor and Prashant Bansode. We're working closely with Jeff Beehler, Rob Caron, Graham Barry, and Bijan Javidi on the VSTS side to bring you the guidance you need. Send your feedback, fan mail and hate mail to VSGuide@microsoft.com
Some readers asked to hear more on how I use my Scannable Outcome Lists in conjunction with My Personal Approach for Daily Results. Here's the work flow in a nutshell ...
MondaysOn Mondays, I figure out my key outcomes for the week. To do this:
I keep my inbox completely empty, so the only items are what comes in over the weekend. The empty inbox is particularly important for me. I get ~150 mails directly to me each day, and I send about that, so I can't be a paper shuffler. For my Scannable Outcome Lists, I use a flat list of posts in Outlook. I name each post according to category: Body, Career, Mind, Project X, Project Y .. etc.
As I scan, I use four guiding questions:
As I scan, I also do some quick shuffling:
I get a few outcomes from this
I have weekly iteration meetings with my team on Mondays, so this information helps me shape the outcomes with my team.
DailyEach day, I construct my Daily Outcomes list. Since I did the bulk of the work on Monday for identifying key priorities, this is a fast exercise. In fact, it's usually 5 minutes. It's as fast as it takes me to open a new post in Outlook, name it the current day (e.g. 02-25-07) and write the key outcomes down. Throughout the day, I add to this. I fish my email stream throughout the day for relevant actions and I add these to the current day's daily outcome. If it's a longer team outcome, I list it under the relevant Scannable Outcome List.
FridaysThis is the day where I do more reflection. To do this:
As I scan, I ask some guiding questions:
I'll note that underlying my approach is my belief that important things should float to the top, less important should slough off, and I should be able to deal with change. Having my Scannable Outcomes keeps me grounded in what's important vs. urgent. This to me is the key to driving versus reacting. If an area is slipping that I want to improve, I narrow my focus and concentrate on that. There's few problems that withstand sustained focus.
Well, that's the heart of the approach. What I like most about this approach is that it's low-overhead and it works. I've done away with over-engineered approaches, where you die the death of a 1000 paper cuts in administration. I also like this approach because it's systematic, yet holistic and flexible. Basically, it's designed for getting real results, in real life.
When I tackle a problem domain, I first frame out the space. To do this, I list out scenarios and sub-scenarios. I group the scenarios under categories. Sometimes categories come first, sometimes scenarios do. I call the result, a Scenario Frame.
I use Scenario Frames to evaluate platform, tools, and guidance. I also use them for product design, innovation, competitive assessments, subject matter expert reviews, arch and design reviews, and as a way to build shared understanding of a problem space.
Here's a Scenario Frame Example my team is creating to enumerate and evaluate Source Control scenarios in VSTS 2005:
What's your favorite tool for framing out problem spaces?
We have a new Performance Testing Guidance project in progress. Our team includes some of the original members from Improving .NET Application Performance as well as some new faces. We're tackling various flavors of performance testing (stress, load, capacity) as well as how to bake performance testing into your life cycle. We're also tackling how to use Visual Studio 2005 for effective performance testing.
We're building our performance testing BOG (Body of Guidance) in three parts:
This factoring let's us create both a focused set of timeless performance testing practices, as well as a set of very specific practices for getting the most out of the tool. You can pick the modules you need for your tasks at hand.
At the end of each day, I ask myself the following:
I use these questions to reflect on daily improvements as well as course correct. I also use them to appreciate life's little lessons each day. It's a simple practice but it helps make sure I don't slip into life's auto-pilot mode. What's interesting too, is this simple practice can actually raise your happiness thermometer, according to Do You Have What It Takes to Lead a Happier Life?
I realized another key for helping manage To Dos. It's having scannable lists of outcomes. I keep flat lists of outcomes chunked by area or project. These aren't the next actions. They're the results I want to accomplish. They act as prompts to help me quickly identify next actions.
I keep lists for all my various areas for outcomes:
In a single view, I can first scan all of my areas. I can then quickly scan any particular area for outcomes. What I like about this approach is that I get a bird's-eye view of all the areas that I'm working on. Because I like to focus on a given area for results, I could easily neglect areas. This approach keeps important things on my radar and helps keep me balanced.
I use my scannable outcome lists in conjunction with my personal approach for daily results.
We released the Enterprise Library Test Guide. I plan on analyzing the sections on security and performance testing. I do like the focus on testing for compliance with recommended practice over testing for all the permutations of bad (whitelist over blacklist testing).
How do you communicate design decisions? … Srinath sent me a helpful link on the Task-Analysis Grid. A Task Analysis Grid is effectively columns of scenarios along with sub-tasks to complete the task.
Here's the key points:
In practice, I think the Task-Analysis Grid is useful for communicating user experiences and high-level product design. For driving engineering and project management, I use Scenario Grids. Scenario Grids are useful for figuring out baseline releases, incremental releases, dependencies, as well as doing scenario-based evaluations and competitive assessments. I'll post more on building Scenario Grids another day.