Looking for:
Professional scrum development with microsoft visual studio 2012 free
See what I did? I solved the feedback and interruption problems with a single solution. Actively listening plus HARD communication is a recipe for successful collaboration.
During a recent Sprint Retrospective meeting, Scott the Scrum Master brought up his observations made during the Sprint. He witnessed a few developers having difficulty conversing respectfully with each other as well as with stakeholders during a couple of meetings. As a team, they decided to improve their communication abilities, specifically their active listening skills.
Scott did some searching online and found several websites dedicated to the subject. During the next few Sprints, Scott coached the team as they adopted more and more of the techniques that they learned. I think we can all agree that communication and collaboration provides more value when practiced face to face, rather than remotely.
At least I would hope that everyone knows this, because we experience it every day of our lives. When two people communicate face to face, they exchange more than just words.
There are facial expressions, body language, and other nonverbal gestures. This kind of sideband data can be just as important, if not more important, than the text that is exchanged. Thank you, collocated Product Owner. You just gave me back 20 minutes of my day. Remember that Scrum has several formal events meetings built into the framework where collaboration can occur. These are short, collaborative, time-boxed meetings with the specific purpose of solving a problem.
For example, if two developers need to discuss something with the Product Owner, but all the conference rooms are booked, they should meet anyway, somewhere, anywhere. To some degree, business formalities, and even etiquette, go out the window during the Sprint when the Development Team is in the zone, developing and generating business value. When forming a new Development Team, collocation should be a requirement. This is not just a nice-to-have feature.
The Product Owner should be nearby too, but not necessarily in the same room. This way, the face-to-face communication can occur on demand. Fellow Professional Scrum Developer Simon Reindl suggests bringing a geographically dispersed team together periodically. This is especially true at the beginning of a new project, so they know with whom they are working. Professional Scrum developers know the value of collocation, and they strive for it.
That said, there may be cultural, political, or financial reasons for not collocating the Development Team. This is the reality that I see as I visit larger organizations. When I hear that, I hope that somebody, somewhere is doing the math on that, taking into account the decreased quality of the product and the process. Even if this decrease is not detectable or measurable, the decision makers should consider what the increase in quality could be if they were to bring the entire team together.
Of course not. They absolutely can be professional and the team absolutely can collaborate, deliver high-quality software, and create business value. That said, an attribute of a professional Scrum developer is to inspect and adapt constantly, such as looking for ways to improve the process. Collocating a dislocated team is one of the biggest improvements that can be made, usually resulting in an increase of quality and Velocity.
Most organizations consider their custom software as a strategic advantage over their competitors. I will sometimes ask executives where they would be without their line-of-business LOB application or public-facing website. They all agree that it would be a complete disaster. Next, I ask them why they try to save money by limiting the capabilities and productivity of the team developing that custom software. I recently had a conversation with an IT director of a very large organization.
He explained to me that the Product Owner worked out of the main office, as did the programmers. The testers were overseas—nearly 10 time zones away. He said the programmers would code a feature and then go home for the night. The testers would come in, download the binaries, begin testing, and run into a bug. This blocked them from doing any further testing until the developers could fix it.
The programmers would come in the next day, see the lack of progress, fix the bug, and have to wait until the end of the day for the testers to do their thing.
Sometimes this dance would take three to four days before testing could proceed. He asked me how TFS could help him. He told me it was because they save money by sending the work offshore. Having the entire Development Team work in a shared, common room can be a good thing. Whiteboards containing plans and design notes are visible to everyone. Artifacts such as the Sprint Backlog and burndown chart can be updated easily and seen by everyone. During critical design points, the team room can become a war room of sorts as the developers move from strategic planning to tactical planning.
Communication becomes more open and happens in real time. Developers tend to focus their productivity toward solving problems, while minimizing time spent on wasteful activities. Team rooms allow everyone, including stakeholders, to feel that buzz that I mentioned in the beginning of the chapter. However, not every developer wants to work in a war room every day.
There needs to be the opportunity to have private conversations, take phone calls, or just take a timeout from the rest of the team. Developers are smart and can self-organize to come up with solutions for these requirements. Ideally, the managers and the organization trust their developers to the point where they can accommodate their needs.
Generating business value in the form of working software is a way for the Development Team to earn that trust. Some personalities and cultures see collocation as an impediment.
These developers may actually be counterproductive in such an environment. Remember that Scrum is about people, and people are just human. Their idiosyncrasies map directly to their ability to collaborate and work effectively as a team.
Perhaps for these people, being in close proximity to, but not in the same shared room with, the rest of the team is good enough at first.
A strong Scrum Master, as well as open and honest Sprint Retrospectives, can be used to improve this. An open-space team room is not the same thing as an open-plan office. Open-plan offices are typically inhabited by employees working on different tasks for different projects. Open-space team rooms are inhabited by developers working on a common software product. Both environments can generate noise, but the type of conversations found in an open-plan office will typically be more contrasting and thus, more distracting.
My recommendation is to set up a team room and just try it out. See if management will let the Development Team take over one of the conference rooms for a Sprint or two. If, during the Sprint Retrospective, the Development Team honestly believes that they were productive, then the Scrum Master can work with management to create a more permanent, open-space room. The Development Team has been collocated since day one, with Paula the Product Owner in a nearby office.
During the Sprint, they regularly meet and collaborate whenever and wherever it is required. Day to day, the developers sit near each other in a large, open-space room with a half-dozen whiteboards approximately one for each PBI. When one of the developers needs to concentrate or requires some personal space, he or she will put on headphones or go to a quieter room down the hall.
When a developer has to travel or otherwise work remotely, the team will set up a dedicated computer with an always-on Skype connection, including video. Scott the Scrum Master has done a good job of educating the organization. Scott still has to remind them from time to time.
High-performance Scrum Development Teams know to avoid meetings, if possible. I am talking about all the other meetings that an organization might require its technical staff to attend. Unfortunately, some of these meetings cannot be avoided.
They are a fact of life and a requirement to keep your job and get paid. When you are invited to such a meeting, try to identify its purpose and expected outcome. I know many developers who will not accept a meeting invitation if no clear agenda or objective is given. From this information, hopefully you can determine who the intended audience should be.
Will the meeting be technical? Will decisions be made? Being a proxy for the Development Team at meetings like this is one of his or her duties and allows the Development Team to what they do best. If the tables are ever turned, and you find yourself organizing a meeting, you can follow the same advice:.
When someone who is versed in Scrum sets up and runs a meeting, he or she will end up sharing good behaviors and practices, such as transparency, active listening, and time-boxing.
This is a good way to get others in the organization more educated on Scrum and some of its attributes and practices. If appropriate, email any retrospective notes to the attendees, including action items. More importantly, the person will be more open to collaborating on a shared solution, which should always be the goal to avoid discussions becoming polarized. Paula the Product Owner and Scott the Scrum Master are good at running interference for the development team.
For meetings that are not related to the development of the software product, Scott will try to attend as a proxy for the Development Team. Collaboration means working with people. This typically means dividing the work between two or more individuals and working together.
Both the process of dividing the work and the actual working together with others can require intense concentration. Getting into this productive state, otherwise known as the flow or the zone , can take time. Getting out of that state prematurely, as caused by any kind of interruption, can be considered waste. The irony is that collaboration requires interruption, and you will need to get used to it and master it.
We are taught at a young age that it is disrespectful to interrupt others. Your instinct should be not to interrupt them. Stopping to take a mental assessment may actually kick you out of the zone. High-performance Scrum developers know how to minimize interruptions in order to maximize productivity.
There have been numerous books, blog posts, and white papers written about being more productive. Exit Microsoft Outlook Email can be a great productivity tool, but it can waste a lot of your time as well. Try to check email only three times a day: at the start of your day, after lunch, and before leaving.
The exception to this is if the tool is used by the Development Team to share code or quick questions and feedback.
Limit Internet searches Developers can spend their whole day on the Internet if they are not careful. Time-box the search and keep the scope to just researching the problem at hand. He doesn’t really care if there are other points of view – everything that contradicts with his beliefs is “evil” and “wrong” and “stupid”.
It would be a nice book, if rewritten by someone reasonable. This book lacks the HOW. There’s no code samples, no sample project and it’s very hard for any beginner to get a grip on it, it’s like a book to scrum developers learn what VS has to offer, nothing more.
It’s kind of useless, since the author don’t teach how to do stuff most of the time, he just say, go to that place and do this. One person found this helpful. I’ve taken my Professional Scrum Developer training from Richard last December, just around the time his book was released. This is well reflected in his book. There is a very nice mix of theory, process and technology as well as the all important human side to software development.
Given that there are so many open source tools, add-ons and other libraries that can help implementing Scrum and extend Visual Studio, you will not find a lot of in-depth discussion on the non-Microsoft solutions, but Richard does provide enough information to know where to look for more information and to have an idea of what’s out there.
The first couple of chapters go into the theory of scrum and the practice without the use of tools. These chapters are great for any reader, both management, developer or just stakeholder to learn more about the process when applied to general.
NET development. Then the planning elements are discussed, both from the Web Access, Excel, Test Manager and other tooling point of view. These topics are still great for any reader, as long as they use TFS once in a while. Then there are a number of chapters that dive into the tools and technology. The last chapters dive into the hardest part of scrum, continuous improvement, inspect and adapt and the general prevention of flaccid scrum.
These chapters are important for everyone who has been doing scrum for a while and wants to up their game. As well as for teams starting out with scrum so that they know what they might expect on their path towards a high performing scrum team.
I really like the balance between real world examples, humor, tips and tricks and short side steps that provide additional perspectives from other Professional Scrum Developers, Masters and Trainers. There is not just one way to become a high performing scrum developer. We’re all on our own journey towards continuous improvement.
This book is great to bring along for the ride. As a Scrum geek, I really enjoyed this book. While I am no longer a hands-on developer, I am a certified ScrumMaster and work with teams in the Microsoft stack.
It was easy to read, easy to comprehend much like Scrum , and provides prescriptive, easy to implement steps on how to run your project utilizing the Microsoft’s ALM products. So as mentioned, this book is not just for the hands-on developer, but extremely beneficial to anyone on the “development team” by Scrum definition. While there are similar books for TFS , the refresh for is quite nice, as there are some major enhancements. Richard does a great job at utilizing these enhancements and pulling them all together in this collection.
Richard easily had another book in his back pocket filled with tips, advice and anecdotes on both Scrum and Visual Studio See all reviews. Your recently viewed items and featured recommendations. Back to top. Get to Know Us. Make Money with Us. Amazon Payment Products. Let Us Help You. Amazon Music Stream millions of songs. Amazon Advertising Find, attract, and engage customers. Amazon Drive Cloud storage from Amazon. Alexa Actionable Analytics for the Web. Sell on Amazon Start a Selling Account.
AmazonGlobal Ship Orders Internationally. ComiXology Thousands of Digital Comics. DPReview Digital Photography. Shopbop Designer Fashion Brands. Deals and Shenanigans. Ring Smart Home Security Systems. Blink Smart Security for Every Home.
❿
❿
Professional scrum development with microsoft visual studio 2012 free.Professional Scrum Development with Microsoft Visual Studio 2012
Duration: Approximately 60 minutes. Cost: FREE Scrum and Visual Studio make for a powerful combination. Organizations that can leverage both will. It is a free (and ridiculously simple) screen-sharing tool for meetings on the fly. You can learn more at replace.me In this section, I. This means that Visual Studio can be adopted gradually by a Scrum Development Team that already uses Visual Studio , with no friction and no need. In this chapter from Professional Scrum Development with Microsoft Visual Studio , Richard Hundhausen looks at some practices and tools. Start reading Professional Scrum Development with Microsoft Visual Studio for free online and get access to an unlimited library of academic and.❿
Professional scrum development with microsoft visual studio 2012 free
There is a very nice mix of theory, process and technology as well as the all important human side to software development. There is not just one way to become a high performing scrum developer. Hopefully, Microsoft will give us a CurrentIteration macro, or something like it, to use in our queries some day soon. Approximately EUR 4. Report this item Report this item – opens in new window or tab. Payment methods. Amazon Drive Cloud storage from Amazon. Over time, the Development Team realized that in-person conversations at a whiteboard provide the most value. When it comes time to meet and collaborate with members of your Scrum Team or stakeholders, here are some tips to consider:.
❿